Advertisements

Home » Information Security Risk Management

Information Security Risk Management

An understanding of risk and the application of risk assessment methodology is essential to being able to efficiently and effectively create a secure computing environment.The fundamental precept of information security is to support the mission of the organization. All organizations are exposed to uncertainties, some of which impact the organization in a negative manner.The organization must  manage these uncertainties. Managing uncertainties is not an easy task. Limited resources and an ever-changing landscape of threats and vulnerabilities make completely mitigating all risks impossible. Therefore, the organization  must have a toolset to assist them in sharing a commonly understood view with IT and business managers concerning the potential impact of various IT security related threats to the mission. This toolset needs to be consistent, repeatable, cost-effective and reduce risks to a reasonable level. Risk management is nothing new. There are many tools and techniques available for managing organizational risks. There are even a number of tools and techniques that focus on managing risks to information systems.

Risk Management as currently stated in ISO 27001:2013

6 Planning

6.1 Actions to address risks and opportunities

6.1.1 General

While planning for the information security management system, the organization must consider the internal and external issues as identified in Clause 4.1 (Understanding the organization and its context) and the  requirements of the interested parties relevant to information security referred to in 4.2 (Understanding the needs and expectations of interested parties) to determine its risks and opportunities. The organization must  ensure the information security management system can achieve its intended outcomes, prevent, or reduce, undesired effects; and achieve continual improvement. The organization must plan  adequate actions  to address these risks and opportunities. The organization must also plan to integrate and implement the actions into its information security management system processes; and evaluate the effectiveness of these actions.

6.1.2 Information security risk assessment

The organization must define and apply an information security risk assessment process by establishing and maintaining  information security risk criteria that includes  the risk acceptance criteria  and  criteria for performing information security risk assessments; The organization must ensure that repeated information security risk assessments produce consistent, valid and comparable results. The organization must identifies the information security risks. The organization must  apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability for information within the scope of the information security management system  and must  identify the risk owners. The organization must analyse  the information security risks. The organization must  assess the potential consequences that would result if the risks identified  were to materialize.The organization must also  assess the realistic likelihood of the occurrence of the risks identified; and  determine the levels of risk. The organization must evaluate the information security risks. They must  compare the results of risk analysis with the risk criteria established  and prioritize the analysed risks for risk treatment. The organization must retain documented information (keep records) about the information security risk assessment process.

6.1.3 Information security risk treatment

The organization must define and apply an information security risk treatment process. It must  select appropriate information security risk treatment options, taking account of the risk assessment results. It must  determine all controls that are necessary to implement the information security risk treatment options chosen. The organization can chose to design controls as required, or identify them from any source. A comprehensive list of  Control objectives and controls are listed in Annex A of ISO 27001:2015 ( Reference control objectives and controls). While determining controls for the organization, it must  verify that no necessary controls have been omitted or overlooked. Control objectives are implicitly included in the controls chosen. The control objectives and controls listed in Annex A are not exhaustive and additional control objectives and controls may be needed. The organization must  produce a Statement of Applicability that contains the necessary controls  and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from Annex A. The organization must  formulate an information security risk treatment plan; and obtain risk owners approval of the information security risk treatment plan and acceptance of the residual information security risks. The organization must retain documented information(keep records) about the information security risk treatment process.

What Is Risk With Respect To Information Systems?

ISO 27000 defines Risk as “effect of uncertainty on objectives” , where effect is is a deviation from the expected – positive or negative and  Uncertainty is the state, even partial, of deficiency of information related tq understanding or knowledge of, an event ,its consequence , or likelihood. Risk is often characterized by reference to potential events and consequences, or a combination of.these, Risk is often expressed in terms of a combination of the consequences  of an event including changes in the circumstances and the associated likelihood of occurrence. In the context of information security management systems, information security risks can be expressed as effect of uncertainty on information security objectives. information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization

.Risk is the potential harm that may arise from some current process or from some future event. Risk is present in every aspect of our lives and many different disciplines focus on risk as it applies to them. From the IT security perspective, risk management is the process of understanding and responding to factors that may lead to a failure in the confidentiality, integrity or availability of an information system. IT security risk is the harm to a process or the related information resulting from some purposeful or accidental event that negatively impacts the process or the related information. Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.

Threats

According to ISO 27001, Threats can be defined as “potential cause of an unwanted incident which may result in harm to a system or organization”. It has also be defined as “The potential for a threat source to accidentally trigger or intentionally exploit a specific vulnerability.” Threat source can be defined as “Intent and method targeted at the intentional exploitation of a vulnerability  a situation and method that may accidentally trigger a vulnerability.”
The threat is merely the potential for the exercise of a particular vulnerability. Threats in themselves are not actions. Threats must be coupled with threat-sources to become dangerous. This is an important distinction when assessing and managing risks, since each threat-source may be associated with a different likelihood, which, as will be demonstrated, affects risk assessment and risk management. It is often expedient to incorporate threat sources into threats. The list below shows  example of some  of the possible threats to information systems.

Examples of Threats with Threat Sources Taken into Consideration

Vulnerability:

ISO 27001 defines Vulnerability as” weakness of an asset or control that can be exploited by one or more threats.” Vulnerability can also be defined as a flaw or weakness in system security procedures, design, implementation, or internal controls that could be accidentally triggered or intentionally exploited and result in a security breach or a violation of the system’s security policy.
Vulnerability can be a flaw or weakness in any aspect of the system. Vulnerabilities are not merely flaws in the technical protections provided by the system. Significant vulnerabilities are often contained in the standard operating procedures that systems administrators perform, the process that the help desk uses to reset passwords or inadequate log review. Another area where vulnerabilities may be identified is at the policy level. For instance, a lack of a clearly defined security testing policy may be directly responsible for the lack of vulnerability scanning. Here are a few examples of vulnerabilities related to contingency planning/ disaster recovery:

  • Not having clearly defined contingency directives and procedures
  • Lack of a clearly defined, tested contingency plan
  • The absence of adequate formal contingency training
  • Lack of information (data and operating system) backups
  • Inadequate information system recovery procedures, for all processing areas (including networks)
  • Not having alternate processing or storage sites
  • Not having alternate communication services

How Is Risk Assessed?

The principle reason for managing risk in an organization is to protect the mission and assets of the organization. Therefore, risk management must be a management function rather than a technical function. It is vital to manage risks to systems. Understanding risk, and in particular, understanding the specific risks to a system allow the system owner to protect the information system commensurate with its value to the organization. The fact is that all organizations have limited resources and risk can never be reduced to zero. So, understanding risk, especially the magnitude of the risk, allows organizations to prioritize scarce resources.
Risk is assessed by identifying threats and vulnerabilities, then determining the likelihood and impact for each risk. It’s easy, right? Unfortunately, risk assessment is a complex undertaking,usually based on imperfect information. There are many methodologies aimed at allowing risk assessment to be repeatable and give consistent results. The general process of risk assessment is discussed below.

1 Quantitative Risk Assessment
Quantitative risk assessment draws upon methodologies used by financial institutions and insurance companies. By assigning values to information, systems, business processes, recovery costs, etc., impact, and therefore risk, can be measured in terms of direct and indirect costs. Mathematically, quantitative risk can be expressed as Annualized Loss Expectancy (ALE). ALE is the expected monetary loss that can be expected for an asset due to a risk being realized over a one-year period.

ALE = SLE * ARO

Where:

  • SLE (Single Loss Expectancy) is the value of a single loss of the asset. This may or may not be the entire asset. This is the impact of the loss.
  • ARO (Annualized Rate of Occurrence) is how often the loss occurs. This is the likelihood.

Mathematically, this gets complicated very quickly, involving statistical techniques. While utilizing quantitative risk assessment seems straightforward and logical, there are issues with using this approach with information systems. While the cost of a system may be easy to define, the indirect costs, such as value of the information, lost production activity and the cost to recover is imperfectly known at best. Moreover, the other major element of risk, likelihood, is often even less perfectly known. For example, what is the likelihood that someone will use social engineering to gain access to a user account on the accounting system?
Therefore, a large margin of error is typically inherent in quantitative risk assessments for information systems. This might not always be the case in the future. As the body of statistical evidence becomes available, trends can be extrapolated on past experience. Insurance companies and financial institutions make excellent use of such statistics to ensure that their quantitative risk assessments are meaningful, repeatable and consistent. Typically, it is not cost-effective to perform a quantitative risk assessment for an IT system, due to the relative difficulty of obtaining accurate and complete information. However, if the information is deemed reliable, a qualitative risk assessment is an extremely powerful tool to communicate risk to all level of management. Quantitative risk measurement is the standard way of measuring risk in many fields, such as insurance, but it is not commonly used to measure risk in information systems. Two of the reasons claimed for this are 1) the difficulties in identifying and assigning a value to assets, and 2) the lack of statistical information that would make it possible to determine frequency. Thus, most of the risk assessment tools that are used today for information systems are measurements of qualitative risk.

2 Qualitative Risk Assessment
Qualitative risk assessments assume that there is already a great degree of uncertainty in the likelihood and impact values and defines them, and thus risk, in somewhat subjective or qualitative terms. Similar to the issues in quantitative risk assessment, the great difficulty in qualitative risk assessment is defining the likelihood and impact values. Moreover, these values need to be defined in a manner that allows the same scales to be consistently used across multiple risk assessments. The results of qualitative risk assessments are inherently more difficult to concisely communicate to management. Qualitative risk assessments typically give risk results of “High”, “Moderate” and “Low”. However, by providing the impact and likelihood definition tables and the description of the impact, it is possible to adequately communicate the assessment to the organization’s management.

1 Identifying Threats
As was alluded to in the section on threats, both threat-sources and threats must be identified. Threats should include the threat-source to ensure accurate assessment. Some common threat-sources include:

  • Natural Threats—floods, earthquakes, hurricanes
  • Human Threats—threats caused by human beings, including both unintentional (inadvertent data entry) and deliberate actions (network based attacks, virus infection, unauthorized access)
  • Environmental Threats—power failure, pollution, chemicals, water damage

Individuals who understand the organization, industry or type of system (or better yet all three) are key in identifying threats. Once the general list of threats has been compiled, review it with those most knowledgeable about the system, organization or industry to gain a list of threats that applies to the system.
It is valuable to compile a list of threats that are present across the organization and use this list as the basis for all risk management activities. As a major consideration of risk management is to ensure consistency and repeatability, an organizational threat list is invaluable.

 The above Table  presents the typical threat agents that can adversely affect the information security of an agency’s information assets. They are categorised into threat groups to enable agencies 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 an agency to consider the threats from employees and external attackers rather than each type of individual or external organisations threat agents but they may need to consider each type of technical, accidental and natural event.

A threat agent’s motivation may be accelerated or moderated by other factors such as their capability (e.g., equipment, expertise, experience etc.) and whether there is an opportunity (e.g., the employee has full access to source code or the information system is exposed to the Internet etc.) for them to exploit vulnerabilities in the agency’s information system or service. Therefore agencies should also consider the factors that may influence a threat agent’s intention to attempt to exploit a vulnerability.

2 Identifying Vulnerabilities
Vulnerabilities can be identified by numerous means. Different risk management schemes offer different methodologies for identifying vulnerabilities. In general, start with commonly available vulnerability lists or control areas. Then, working with the system owners or other individuals with knowledge of the system or organization, start to identify the vulnerabilities that apply to the system. Specific vulnerabilities can be found by reviewing vendor web sites and public vulnerability archives, such as Common Vulnerabilities and Exposures or the National Vulnerability Database . If they exist, previous risk assessments and audit reports are the best place to start. Additionally, while the following tools and techniques are typically used to evaluate the effectiveness of controls, they can also be used to identify vulnerabilities:

  • Vulnerability Scanners – Software that can examine an operating system, network application or code for known flaws by comparing the system (or system responses to known stimuli) to a database of flaw signatures.
  • Penetration Testing – An attempt by human security analysts to exercise threats against the system. This includes operational vulnerabilities, such as social engineering
  • Audit of Operational and Management Controls – A thorough review of operational and management controls by comparing the current documentation to best practices (such as ISO 17799) and by comparing actual practices against current documented processes.

It is invaluable to have a base list of vulnerabilities that are always considered during every risk assessment in the organization. This practice ensures at least a minimum level of consistency between risk assessments. Moreover, vulnerabilities discovered during past assessments of the system should be included in all future assessments. Doing this allows management to understand that past risk management activities have been effective

3 Relating Threats to Vulnerabilities
One of the more difficult activities in the risk management process is to relate a threat to a vulnerability. Nonetheless, establishing these relationships is a mandatory activity, since risk is defined as the exercise of a threat against a vulnerability. This is often called threat-vulnerability (T-V) pairing. Once again, there are many techniques to perform this task. Not every threat-action/threat can be exercised against every vulnerability. For instance, a threat of “flood” obviously applies to a vulnerability of “lack of contingency planning”, but not to a vulnerability of “failure to change default authenticators.” While logically it seems that a standard set of T-V pairs would be widely available and used; there currently is not one readily available. This may be due to the fact that threats and especially vulnerabilities are constantly being discovered and that the T-V pairs would change fairly often. Nonetheless, an organizational standard list of T-V pairs should be established and used as a baseline. Developing the T-V pair list is accomplished by reviewing the vulnerability list and pairing a vulnerability with every threat that applies, then by reviewing the threat list and ensuring that all the vulnerabilities that that threat-action/threat can act against have been identified. For each system, the standard T-V pair list should then be tailored.

 4 Defining Likelihood
Determining likelihood is fairly straightforward. It is the probability that a threat caused by a threat-source will occur against a vulnerability. In order to ensure that risk assessments are consistent, it is an excellent idea to utilize a standard definition of likelihood on all risk assessments. Be very careful in setting up the likelihood definitions.

Sample Likelihood Definitions

Table above  shows  a qualitative scale that can be used to assess the likelihood of a risk eventuating. As shown in  the above Table  it is important to define what each rating level means. This ensures that risks can be assessed in a consistent manner by providing 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. The most important thing is to make sure that the definitions are consistently used, clearly communicated, agreed upon and understood by the team performing the assessment and by organizational management.

5 Defining Impact
In order to ensure repeatability, impact is best defined in terms of impact upon availability, impact upon integrity and impact upon confidentiality.

Simple Impact Scale

The Figure above (Simple Impact Scale) illustrates a workable approach to evaluating impact by focusing attention on the three aspects of information security. However, in order to be meaningful, reusable and easily communicated, specific ratings should be produced for the entire organization. Figure below (Detailed Impact Scale) shows these specific values.

Detailed Impact Scale

There are advantages and disadvantages to each approach. For example, it is easier to create a simple impact scale. However, simple scales are typically more difficult to use when assessing and rating risks, as workshop participants are more likely to interpret the definitions based on their own experience. Conversely, it requires more effort to define a detailed scale. However, workshop participants are more likely to consistently assess the impact of the identified risks when using a detailed scale, as the descriptions are not so easy to misinterpret. All impacts need to be seen in a business context, and be informed by the business. The effect of a risk event materialising should be assessed using the agency’s approved risk rating scales. 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 moderate impacts might be judged to have a significant impact when they are combined). Rating the impact of a risk should include a consideration of any possible knock-on effects of the consequences of the identified risks, including cascade and cumulative effects.

6 Assessing Risk
Assessing risk is the process of determining the likelihood of the threat being exercised against the vulnerability and the resulting impact from a successful compromise. When assessing likelihood and impact, take the current threat environment and controls into consideration. Likelihood and impact are assessed on the system as it is operating at the time of the assessment. Do not take any planned controls into consideration. 

Risk Matrix

Table above presents a 5×5 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.Table  below provides an example of risk escalation and reporting table. It defines who must be informed and has authority to accept risk based on its magnitude.

Risk Escalation and Reporting

Risk Assessment Process

A risk assessment process is designed to enable Organizations 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. Figure  below presents the risk management lifecycle

Risk Management Lifecycle

The process has incorporated the Establish Context phase into the risk assessment process. This ensures that risks are analysed and evaluated within the relevant business context. The output of the risk assessment process is a report that captures the information security risks associated with the information system or service taking into consideration the agency’s business context.

1.Establishing the Context

During a risk assessment it is essential to establish the business and technical context of the information system being reviewed. Establishing the context 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
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 official information stored, processed and/or transmitted by the information system must be assigned an official classification based on Security in the Government Sector (SIGS).
  • 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 members of the public or another agency’s staff.
  • 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.
  • Information Protection Priorities – the business owner’s prioritisation of the confidentiality, integrity, availability and privacy of the information stored, processed or transmitted by the information system.

Technical Context
Establish the technical context to provide a basic understanding of the security posture of the information system. A risk assessment may be performed for an information system that is already in production or as part of the development lifecycle of a new 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 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 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.

2 Risk Identification

The risk identification phase seeks to create 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. Although there are numerous tools and techniques that can be used to facilitate the identification and analysis of risks it is recommended that a multidisciplinary workshop discussion be used. The workshop should include the business and service owners (or their nominated delegates) and subject matter experts from both the business and ICT. In order to manage risk, the potential threats to the information systems need to be identified. This is achieved by 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. 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.
The following provides an overview of the techniques that should be used to ensure that comprehensive lists of relevant risk are identified:

  • People with the appropriate knowledge should be involved in identification of risks. Discussions must include the business owner and subject matter experts who can provide relevant and up-to-date information during the process; and
  • Group discussions and workshops to facilitate the identification and discussion of the risks that may affect the businesses objectives.

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):

(Uncertain event) occurs, leading to (effect on objectives), 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 Privacy Commissioner, 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 unauthorised party, and reputational damage to the Minister and agency 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.

Although the risk statement captures the consequences (i.e., the effect on objectives) of the risk eventuating it is useful to document them separately as well. The consequences should be stated in business not technical terms. For example:

  • Reputational damage to the Organization;
  • IN CONFIDENCE information is disclosed to an unauthorised party;
  • Breach of the IT Act 2000;
  • Service delivery is impacted due to a loss of productivity;
  • Loss of confidence in the service by key stakeholders.

3. Risk Analysis

Once the relevant risks have been identified the likelihood and impact of them eventuating must be assessed and rated. Typically the likelihood and impact of a risk eventuating are rated using a qualitative scale.

  1. Impact Assessment
    Assess the impact of the risk eventuating with no controls in place. This will inform the gross 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. Likelihood Assessment
    Assess the likelihood of the risk eventuating with no controls in place. This will inform the gross 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.
  3. Risk Rating 
    The risk rating is evaluated using a risk matrix. The risk rating without any controls in place have been assessed is called the gross 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 business and may not require the implementation of any controls to manage them. However, because risk is rarely static they should be added to the agency’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.
  4. 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.

    Types of controls

    The following provides a brief description and some example for each type of control

    • Deterrent Controls – are intended to discourage a potential attacker. For example, establishing an information security policy, a warning message on the logon screen, a lock or security cameras.
    • Preventive Controls – are intended to minimise the likelihood of an incident occurring. 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 – are intended to identify when an incident has occurred. For example, review of server or firewall security logs or Intrusion Detection System (IDS) alerts.
    • Corrective Controls – are intended to fix information system components after an incident has occurred. For example, data backups, SQL transaction log shipping or business continuity and disaster recovery plans.

    It is recommended that a multidisciplinary workshop be used 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 who can identify and describe the current controls that are in place to manage the identified risks must be involved in assessing their efficacy. Where information is available that provides evidence about the effectiveness of the current controls it should be considered during the controls assessment phase.
    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 removed and 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 gross risk and using the risk matrix. For example:

    • A risk scenario with likelihood rating of Possible but Unlikely, and impact rating of Severe would result in an overall risk rating of 19. A control currently in place is highly effective at reducing the impact of the risk. The impact rating is revised to Moderate with the control in place, therefore the residual risk rating is 9;
    • A risk scenario with a likelihood rating of Possible, and an impact rating of Severe would result in an overall risk rating of 22. A control currently in place is effective at reducing the impact of the risk. The impact rating is revised to Significant with the control in place, therefore the residual risk rating is 18; and
    • A risk scenario with a likelihood rating of Almost Certain, and an impact rating of Minor would result in an overall risk rating of 16. 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 8.

4. Risk Evaluation

Once the risk analysis has been completed the residual risks can be evaluated against the agency’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 3 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 agency’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 4 and 25 on the rating scale need to be evaluated and prioritised. Typically 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.

Statement of Applicability

Having conducted the risk assessment and taken decisions regarding the treatment of those assessed risks, the results need to be documented. This produces two documents:

  • Statement of Applicability, and
  • Risk Treatment Plan.

The first lists all the controls listed in Annex A of ISO 27001 and documents whether or not they have been applied within the ISMS, and also identifies additional controls that have been applied. The second maps the selected treatments (and the measures by which they are to be implemented) to the specific risks they are intended to address and is, in effect, a control implementation plan. The Statement of Applicability forms the main link between your risk assessment and the information security you have implemented. The purpose of the Statement of Applicability is to document which controls (security measures) from ISO 27001 Annex A (and thereby the ISO 27002 standard for information security) you will implement, the reason they have been chosen – and for those that have not been chosen – the justification for their exclusion. While the standard does not directly specify this, it has become good practice to also include the following in the Statement of Applicability document:

  • The status of implementation for existing controls
  • A link to the control documentation or a brief description of how each control is implemented
  • A cross-reference to the sources of other requirements, necessitating the controls chosen

Thus, by preparing a good quality Statement of Applicability, you will have a thorough and full overview of which controls you need to implement, why they are implemented, how they are implemented, and how well they are implemented. The two primary sources for the Statement of Applicability are the risk assessment and Annex A of the standard (in reality the Table of Contents of the ISO 27002 standard). Other sources are the controls that currently exist in the organization and external security requirement that the organization has to comply with.

Drafting the Statement of Applicability

As the controls are selected, the Statement of Applicability (SoA) can start being drawn up. This SoA  is documentation of the decisions reached on each control in light of the risk assessment and is also an explanation or justification of why any controls that are listed in Annex A have not been selected.This exercise, of reviewing the list of controls and documenting the reasons numbering as in Annex A of the Standard and this statement explains which controls have been adopted, and identifies those which have not been adopted and sets out the reasons for these decisions. able to coordinate implementation of the complete range of information security controls. A separate forum for information security coordination has not been created as it is considered more effective for this to be handled through the management
The Statement of Applicability will also list those additional controls that the organisation has determined, following its risk assessment, are necessary to counter specifically identified risks. These controls should be listed, either within those control sections whose objectives are supported by the additional controls, or within additional control sections added after those contained in lSO 27001 Appendix A. These additional controls should adopt the Appendix A numbering scheme. it would also be worth documenting how the additional controls were selected.

Road to Statement of Applicability

  1. Identify and Analyse Risks

    To ensure that the controls that are implemented reflect the risks that the organization faces, a risk analysis must be undertaken. The risk analysis starts with an identification of the risks. The identification consists of the following activities

    1. Identify the risks associated with the loss of:
      • Confidentiality
      • Integrity
      • Availability
    2. Identify the risk owners. Secondly the risks must be analysed and evaluated. The analysis consists of the following activities:
    3. Assess the potential consequences that would result if the risks identified were to materialize
    4.  Assess the realistic likelihood of the occurrence of the risks identified
    5. Determine the levels of risk
    6. Compare the analysed risks with the organization’s risk acceptance criteria and establish priorities for treatment
  2. Select Controls

    Where the analysis has determined that the risks are not acceptable, proper action must be taken. The risk treatment options typically are:

    1. Applying appropriate controls
    2. Knowingly and objectively accepting risks
    3. Avoiding risks, or
    4. Sharing the associated business risks with other parties, e.g. insurers or suppliers

    For those risks where the option a) above is chosen, proper controls must be selected. Fortunately ISO 27002 provides us with a very good catalogue of control objectives and controls for the treatment of risks as well as good guidance on how to implement the controls. In addition to the risk analysis, numerous other sources may come into play when you select controls.Other sources may be:

    • Industry-specific regulatory requirements
    • Contractual security requirements
    • Corporate or Group security requirements which a subsidiary must adhere to

    It is recommended that if the organization wishes to adhere to ISO 27001, the Statement of Applicability is organized according to ISO 27002, and that the various other security requirements are then mapped into the ISO 27002 framework. The Statement of Applicability should for each chosen control document:

    1. The source of the requirement which has led to the selection of the control
    2. The maturity or level of compliance of the control
    3. A reference to where in the source the need for this control is stated OR The reason that the control has not been selected
    4. A short description of the control or a reference to where the control is described
  3. Analyse Gaps

    While this is not a strict requirement of the ISO 27001 standard, it is recommended that once the required controls have been selected, a gap analysis is performed to establish the current state of the implementation of the controls. To ensure the evaluation of the controls is consistent and coherent

  4. Writing the Statement of Applicability

    After having selected the controls and performed a gap analysis on the selected controls, we now have all the information needed to write the Statement of Applicability itself. It is recommended that a structured tool is used to document the Statement of Applicability. That way, it will be possible to work with the content of the Statement of Applicability and, for instance, sort and filter based on compliance level, source for requirements and other parameters.Examples of relevant tools to write the Statement of Applicability are spreadsheets, databases etc. It should be noted, that the Statement of Applicability must not be a one-off exercise, but must be updated when there are changes to the controls, to the compliance level or to the requirements that necessitate the controls.

  5. Plan Risk Treatment

    As noted in the introduction, the Statement of Applicability is a very central document in the information security management system. After the initial version of the Statement of Applicability has been developed, it will be used both when developing the risk treatment plan and when implementing the controls that have been selected during the ‘Select Controls’ activity. The risk treatment plan could be said to be the organization’s security implementation plan, and the primary goal of the plan is to achieve the organization’s security goals.
    When planning the implementation the following factors should be considered:

    1. What will be done?
    2. What resources will be required?
    3. Who will be responsible?
    4. When will it be completed?
    5. How will the results be evaluated?

    Another important factor to consider when planning the security implementation, is the importance of the controls that are being implemented, so the security activities must be prioritized according to:

    • The consequences associated with the risks
    • The likelihood of the risks
    • Legal and other regulatory requirements
  6. Implement Controls

    Once the risk treatment planning has been done, the actual security work starts. Depending on how wide the gap is between the actual and the necessary security levels, this might be a both work intensive and time consuming task. Therefore it is not unusual to see risk treatment plans that stretch several months or even years. During the implementation of the controls, the maturity of the ISMS is improved, and therefore the Statement of Applicability must be updated according to this progress.

  7. Maintaining the Statement of Applicability

    As noted above, the Statement of Applicability must be continually updated, and  previous major updates should be kept, so that the improvements in control implementation and compliance can be documented. Also, as the organization’s risk management approach matures, it is likely that recurring risk assessments may result in updates to the overall risk picture and therefore also to the Statement of Applicability. An updated Statement of Applicability is very useful to document the overall implementation level of the ISMS as well as the effectiveness of the controls that have been implemented.

pdf Example of  Statement of Applicability
Example of Template for  Statement of Applicability

Risk Treatment

According to its definition, Risk Treatment is the process of selecting and implementing of measures to modify risk. The he purpose of assessing risk is to assist management in determining where to direct resources. There are four basic strategies for managing risk: mitigation, transference, acceptance and avoidance.  For each risk in the risk assessment report, a risk management strategy must be devised that reduces the risk to an acceptable level for an acceptable cost. For each risk management strategy, the cost associated with the strategy and the basic steps for achieving the strategy must also be determined.

  1. Mitigation
    Mitigation is the most commonly considered risk management strategy. Mitigation involves fixing the flaw or providing some type of compensatory control to reduce the likelihood or impact associated with the flaw. A common mitigation for a technical security flaw is to install a patch provided by the vendor. Sometimes the process of determining mitigation strategies is called control analysis.
  2. Transference
    Transference is the process of allowing another party to accept the risk on your behalf. This is not widely done for IT systems, but everyone does it all the time in their personal lives. Car, health and life insurance are all ways to transfer risk. In these cases, risk is transferred from the individual to a pool of insurance holders, including the insurance company. Note that this does not decrease the likelihood or fix any flaws, but it does reduce the overall impact (primarily financial) on the organization.
  3. Acceptance
    Acceptance is the practice of simply allowing the system to operate with a known risk. Many low risks are simply accepted. Risks that have an extremely high cost to mitigate are also often accepted. Beware of high risks being accepted by management. Ensure that this strategy is in writing and accepted by the manager(s) making the decision. Often risks are accepted that should not have been accepted, and then when the penetration occurs, the IT security personnel are held responsible. Typically, business managers, not IT security personnel, are the ones authorized to accept risk on behalf of an organization.
    . The measures (i.e. security measurements) can be selected out of sets of security measurements that are used within the Information Security Management System (ISMS) of the organization. At this level, security measurements are verbal descriptions of various security functions that are implemented technically (e.g. Software or Hardware components) or organizationally (e.g. established procedures).
  4. Avoidance
    Avoidance is the practice of removing the vulnerable aspect of the system or even the system itself. For instance, during a risk assessment, a website was uncovered that let vendors view their invoices, using a vendor ID embedded in the HTML file name as the identification and no authentication or authorization per vendor. When notified about the web pages and the risk to the organization, management decided to remove the web pages and provide vendor invoices via another mechanism. In this case, the risk was avoided by removing the vulnerable web pages

Steps for Risk Treatment

  1. Identification of Options

    Having identified and evaluated the risks, the next step involves the identification of alternative appropriate actions for managing these risks, the evaluation and assessment of their results or impact and the specification and implementation of treatment plans. Since identified risks may have varying impact on the organization, not all risks carry the prospect of loss or damage. Opportunities may also arise from the risk identification process, as types of risk with positive impact or outcomes are identified. Management or treatment options for risks expected to have positive outcome include:

    • starting or continuing an activity likely to create or maintain this positive outcome;
    • modifying the likelihood of the risk, to increase possible beneficial outcomes;
    • trying to manipulate possible consequences, to increase the expected gains;
    • sharing the risk with other parties that may contribute by providing additional resources which could increase the likelihood of the opportunity or the expected gains;
    • retaining the residual risk.

    Management options for risks having negative outcomes look similar to those for risks with positive ones, although their interpretation and implications are completely different. Such options or alternatives might be:

    • to avoid the risk by deciding to stop, postpone, cancel, divert or continue with an activity that may be the cause for that risk;
    • to modify the likelihood of the risk trying to reduce or eliminate the likelihood of the negative outcomes;
    • to try modifying the consequences in a way that will reduce losses;
    • to share the risk with other parties facing the same risk (insurance arrangements and organizational structures such as partnerships and joint ventures can be used to spread responsibility and liability); (of course one should always keep in mind that if a risk is shared in whole or in part, the organization is acquiring a new risk, i.e. the risk that the organization to which the initial risk has been transferred may not manage this risk effectively.)
    • to retain the risk or its residual risks;
      In general, the cost of managing a risk needs to be compared with the benefits obtained or expected. During this process of cost-benefit judgments, the Risk Management context established in the first process (i.e. Definition of Scope and Framework) should be taken into consideration. It is important to consider all direct and indirect costs and benefits whether tangible or intangible and measured in financial or other terms.

    More than one option can be considered and adopted either separately or in combination. An example is the effective use of support contracts and specific risk treatments followed by appropriate insurance and other means of risk financing. In the event that available resources (e.g. the budget) for risk treatment are not sufficient, the Risk Management action plan should set the necessary priorities and clearly identify the order in which individual risk treatment actions should be implemented.

  2. Development of Action Plan

    Treatment plans are necessary in order to describe how the chosen options will be implemented. The treatment plans should be comprehensive and should provide all necessary information about:

    • proposed actions, priorities or time plans,
    • resource requirements,
    • roles and responsibilities of all parties involved in the proposed actions,
    • performance measures,
    • reporting and monitoring requirements.

    Action plans should be in line with the values and perceptions of all types of stakeholders (e.g. internal organizational units, outsourcing partner, customers etc.). The better the plans are communicated to the various stakeholders, the easier it will be to obtain the approval of the proposed plans and a commitment to their implementation.

  3. Approval of Action Plan

    As with all relevant management processes, initial approval is not sufficient to ensure the effective implementation of the process. Top management support is critical throughout the entire life-cycle of the process. For this reason, it is the responsibility of the Risk Management Process Owner to keep the organization’s executive management continuously and properly informed and updated, through comprehensive and regular reporting

  4. Implementation of Action Plan

    The Risk Management plan should define how Risk Management is to be conducted throughout the organization. It must be developed in a way that will ensure that Risk Management is embedded in all the organization’s important practices and business processes so that it will become relevant, effective and efficient.
    More specifically, Risk Management should be embedded in the policy development process, in business and strategic planning, and in change management processes. It is also likely to be embedded in other plans and processes such as those for asset management, audit, business continuity, environmental management, fraud control, human resources, investment and project management. The Risk Management plan may include specific sections for particular functions, areas, projects, activities or processes. These sections may be separate plans but in all cases they should be consistent with the organization’s Risk Management strategy (which includes specific RM policies per risk area or risk category). The necessary awareness of and commitment to Risk Management at senior management levels throughout the organization is mission critical and should receive close attention by:

    • obtaining the active ongoing support of the organization’s directors and senior executives for Risk Management and for the development and implementation of the Risk Management policy and plan;
    • appointing a senior manager to lead and sponsor the initiatives;
    • obtaining the involvement of all senior managers in the execution of the Risk Management plan.

    The organization’s board should define, document and approve its policy for managing risk, including objectives and a statement of commitment to Risk Management. The policy may include:

    • the objectives and rationale for managing risk;
    • the links between the policy and the organization’s strategic plans;
    • the extent and types of risk the organization will take and the ways it will balance threats and opportunities;
    • the processes to be used to manage risk;
    • accountabilities for managing particular risks;
    • details of the support and expertise available to assist those involved in managing risks;
    • a statement on how Risk Management performance will be measured and reported;
    • a commitment to the periodic review of the Risk Management system;
    • a statement of commitment to the policy by directors and the organization’s executive.

    Publishing and communicating a policy statement of this type demonstrates to the organization’s internal and external environment the commitment of the executive board to Risk Management and clearly specifies roles and accountability on a personal level.The directors and senior executives must be ultimately responsible for managing risk in the organization. All personnel are responsible for managing risks in their areas of control. This may be facilitated by:

    • specifying those accountable for the management of particular risks, for implementing treatment strategies and for the maintenance of  controls;
    • establishing performance measurement and reporting processes;
    • ensuring appropriate levels of recognition, reward, approval and sanction.

    As it becomes apparent, the actual implementation of security measurements for the underlying IT platform is not part of this activity. Rather, the implementation of action plans is concerned with the actions to be performed to reduce the identified risks. The work necessary at the level of the technical implementation of security measures is conducted within the ISMS, that is, outside the Risk Management process. Last but not least, an important responsibility of the top management is to identify requirements and allocate necessary resources for Risk Management. This should include people and skills, processes and procedures, information systems and databases, money and other resources for specific risk treatment activities. The Risk Management plan should also specify how the Risk Management skills of managers and staff will be developed and maintained.

  5. Identification of Residual Risks

    Residual risk is a risk that remains after Risk Management options have been identified and action plans have been implemented. It also includes all initially unidentified risks as well as all risks previously identified and evaluated but not designated for treatment at that time.
    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 15 (i.e., a likelihood of Almost Never and a impact of Severe) 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.

    Examples of recommended controls to reduce residual risks to an acceptable level are:

    • Implement an appropriate access control lists on shares, folders and files to ensure only authorised personnel can access information stored within the folders.
    • Review the patch management process to ensure that it includes all operating systems, applications and firmware. Ensure monthly maintenance windows are defined and agreed with the business to ensure that patches are implemented regularly and in a timely manner.
    • Implement additional servers and load balancing hardware to ensure that the service scales to meet the businesses requirements and that it meets the availability requirements in the event of a server failure.
    • Implement an operational procedure to test the restoration of data from the backup media to ensure that critical data can be restored.

    It is important for the organizations management and all other decision makers to be well informed about the nature and extent of the residual risk. For this purpose, residual risks should always be documented and subjected to regular monitor-and-review procedures.

Communicating Risks and Risk Management Strategies

Risk must also be communicated. Once risk is understood, risks and risk management strategies must be clearly communicated to organizational management in terms easily understandable to organizational management. Managers are used to managing risk, they do it every day. So presenting risk in a way that they will understand is key. Ensure you do not try to use “fear, uncertainty and doubt.” Instead, present risk in terms of likelihood and impact. The more concrete the terms are, the more likely organizational management will understand and accept the findings and recommendations.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. The perception of a risk can vary significantly. Stakeholders are likely to make judgements on the acceptability of the risk based on their own experience of it, therefore it is important to ensure that their perceptions of the risk, as well as their perceptions of the benefits, are identified and documented and the underlying reasons for their position are clearly understood and addressed. 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.With a quantitative risk assessment methodology, risk management decisions are typically based on comparing the costs of the risk against the costs of risk management strategy. A return on investment (ROI) analysis is a powerful tool to include in the risk assessment report. This is a tool commonly used in business to justify taking or not taking a certain action. Managers are very familiar with using ROI to make decisions. With a qualitative risk assessment methodology, the task is somewhat more difficult. While the cost of the strategies is usually well known, the cost of not implementing the strategies is not, which is why a qualitative and not a quantitative risk assessment was performed. Including a management-friendly description of the impact and likelihood with each risk and risk management strategy is extremely effective. Another effective strategic is showing the residual risk that would be effective after the risk management strategy was enacted.

Sample Risk Management Table

A Plan Of Action & Milestones (POAM) should be part of the risk assessment report presented to management. The POAM is a tool to communicate to management on the proposed and actual completion of the implementation of the risk management strategies. The first step in implementing risk management strategies is to get management to approve the POAM. Afterwards, the various individuals and teams report upon their progress. This in turn is reported to management and tracked as part of the ongoing process of risk management.The POAM contains the risk, the risk management strategy, the Point Of Contact (POC) responsible for implementing the strategy, the resources required and the various milestones that comprise the implementation. For each milestone, a target completion date and an actual completion date is listed. Note that the POAM is a tool to communicate to management, rather than a project management plan.

Sample PAOM

pdf Example of  Risk Assessment Methodology
pdf Example of Risk Treatment Plan
https://youtu.be/EgCX-zcUwRU

Your Donation can make a difference

We have chosen to make our Resources freely and openly available on the web with the hope that it touches the life of thousands of readers who visits us daily. We hope our blog has helped in enhancing the knowledge of our readers and added value to organization and their implementers. We would request you to make donation large and small, so as to provide us the resources needed to distribute, collect, digitize as it is becoming extremely difficult for us to afford the full cost of updating and enriching our site content. Your contribution will ensure that we can keep our blog  up-to-date and add more of the rich resources — such as video — that make a difference for so many worldwide. Your donation will demonstrate your commitment to knowledge as a public good and is an important part of our overall sustainability plan. Your donation is also important in demonstrating to us how much you value the site and motivates us to devote more of our time towards developing this blog.

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at: preteshbiswas@gmail.com or call Pretesh Biswas at +919923345531. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion is also welcome.

[contact-form-7 404 "Not Found"]

 

Advertisements

Pretesh Biswas

Pretesh Biswas

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 1,225 other subscribers

%d bloggers like this: