ITSecurity Office

CRAMM (CCTA Risk Analysis Management & Methodology)

2011-09-26T14:09:00.002+03:00

CRAMM stands for CCTA Risk Analysis Management & Methodology. The main reasons for the development of CRAMM were the need for a rigorous methodology and the deficient methodologies at the time, that were subjective, vulnerability driven and needed experienced personnel to operate them, while their results were less than impressive.

The new methodology should be easy to understand and use, be able to be used for system development, consist an automated tool, it should contain a threat checklist ανδ have the countermeasures built in. CRAMM does risk analysis by combining assets, threats and vulnerabilities to evaluate the risk involved and then it does risk management by suggesting a list of countermeasures. The theoretical model of the system, that CRAMM uses, contains assets Ak, threats vulnerabilities Vi and impacts Ij. CRAMM has thirty-one generic threats and eight impacts. First we assign values to asset/impact pairs, then we identify threat/impact/asset triples, we evaluate threats and vulnerabilities (low, medium, high) and calculate the security requirement (risk) of each threat/impact/asset triple.

CRAMM consists of three stages: the first stage, where we scope the security problem, the second stage, where we evaluate the risk and the third stage, where we select suitable countermeasures.

First stage: The evaluation of the scope of security consists of three steps.

I. The preparation of the project framework takes place. As it is the case with the whole CRAMM procedure, the security consultant that conducts the CRAMM procedure, interviews selected staff to get the information needed. At this point, the arrangement of the initial management meeting takes place, followed by the preparation of the functional specification of the system. The project boundaries are agreed and the physical (hardware, communications, environmental, software, documentation) and data (organised interrelated data) assets are identified and documented. Then, the organisation's structure is documented; the data users and three time periods for unavailability are identified. At the end of all this, the project schedule is prepared, which is the objective of this phase.

II. The security consultant tries to assign values to assets. Assigning values to physical assets is not difficult, as their price is known. What can be difficult is the assignment of values to data assets. This happens because the data is only valuable to somebody during some defined period of time. At this point, the personnel are interviewed, so that the consultant can value the data assets. Questionnaires and tables are used along with worst case scenarios. It is very important that existing countermeasures are ignored and that the interviewees provided accurate and relevant numerical input (not vague descriptions of the impact due to the lack of the data assets). When valuing assets, one should take into account the impact from political embarrassment, personal safety matters, infringement of personal privacy, failure to meet legal obligations, financial loss, disruption of activities, commercial confidentiality. Under certain threats these impacts can become reality, causing from minor losses up to imprisonment and public humiliation. At the end of that phase, a data assets value summary is created.

III. The data results are reviewed just in case some of the value assignments do not correspond to reality. This can happen if the interviewees were not the appropriate ones, or if the interviewer was not experienced. At this point, the CRAMM report is printed and the consultant writes his/her own report that will be given to the management. In the report the consultant's understanding of the client's business must be clearly stated. Then, all the asset valuations have to be agreed upon.

The first stage can pose a series of problems such as the lengthy period it takes to complete. Moreover, bad data grouping can occur if the interviewees or the interviewer are not the appropriate ones. The first stage can also be bogged down in useless detail or the unavailability periods can be incorrect.

Second stage: It is involved with the evaluation of the risk and it consists of four steps.

I. The threat, asset, impact relationships are identified. CRAMM has thirty one generic threats that cover all possible threats form accidents to malicious misconduct. During that step, all meaningful threat/asset combinations are found and impacts are assigned to them. Time and space can be saved by grouping together assets.

II. The threats and vulnerabilities are measured by calculating the threat and vulnerability ratings. The threat rating reflects the likelihood of a threat occurring and takes into account if the threat has happened in the past and who is interested on the assets involved. The vulnerability rating shows if the system makes a threat more likely to happen and also if the system's nature increases the possible extent of damage. This rating takes into account the redundancy built into the system and how easy it is to eavesdrop.

III. The security requirement is calculated. A fixed three dimensional lookup table (matrix) is used; whose elements represent the security requirement under different settings of threat rating, vulnerability rating and asset value. These elements are in the range 1-5 and give the security requirement for every threat/impact/asset triple.

IV. The security requirement values are reviewed to avoid any errors, that would either impose unnecessary expenses for unneeded extra security or would leave the system unprotected. Also, in case there is a limited budget factor a reasonable compromise between the cost and risk must be reached.

The problems imposed by stage two are mainly generated by the fact, that there are too many questions to be asked (approximately 600). The interviewees tend to get bored or be uncooperative. Also, sometimes the answers are objective, so the interview process has to be repeated.

Third stage: It is the last stage of CRAMM, where the appropriate countermeasures are selected.

I. The required countermeasures are identified. The calculated security requirement is a pointer to a set of applicable countermeasures from which "sufficiently powerful" countermeasures are selected. CRAMM contains fifty three countermeasure groups, categorised according to strength (1-5), "cost", security aspect (hardware, software, communications, procedural, physical, personnel, environmental) and sub-group type (to reduce threat, to reduce vulnerability, to reduce impact, to detect, to recover).

II. We compare the required countermeasures with the countermeasures already installed, to find out how many new countermeasures we need to install.

III. We recommend and confirm with the management the new countermeasures and here the work with CRAMM ends.

The problems we get with the third stage are that it generates a lot of output and that it is really hard to identify the already installed countermeasures, because the interviewees' knowledge is sometimes inadequate, or the countermeasures are not truly installed.

The typical time scale for a CRAMM cycle ranges from six days for a small system (one computer, one application), to seventeen days for a medium system (one mini computer, several applications), to thirty days for a large system (a mainframe with sites on several geographic locations).

One problem one can face with CRAMM, is that it requires expert knowledge, the right interviewees and to get the right balance between cost and risk, because even idiots can throw in numbers and get impressive but not appropriate results. It is also time consuming, not particularly green (consumes too much paper) and the reports are sometimes inadequate. Moreover, it doesn't really take into account the security policy of a company, the existing products and the cost of products, and the organisation culture of the company. On the other hand, CRAMM is a rigorous methodology that is becoming the Defacto standard, it is applicable to most systems, it is regularly updated and has a countermeasure database of impressive quality.

To get the best of CRAMM, one must identify the correct people, obtain useful information, avoid getting bogged down in detail, avoid being driven by CRAMM, identify key equipment to the company, start threats' and vulnerabilities' identification and evaluation early and finally start the countermeasures' process early.

ISO/IEC 27005

2011-09-25T23:09:00.001+03:00

ISO/IEC 27005, part of a growing family of ISO/IEC ISMS standards, the 'ISO/IEC 27000 series', is an information security standard published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC).

The purpose of ISO/IEC 27005 is to provide guidelines for information security risk management. It supports the general concepts specified in ISO/IEC 27001 and is designed to assist the satisfactory implementation of information security based on a risk management approach. It does not specify, recommend or even name any specific risk analysis method, although it does specify a structured, systematic and rigorous process from analyzing risks to creating the risk treatment plan.

At around 60 sides, ISO/IEC 27005 is a heavyweight standard although the main part is just 24 pages, the rest being mostly annexes with examples and further information for users. There is quite a lot of meat on the bones, reflecting the complexities in this area.

Although the standard defines risk as “a combination of the consequences that would follow from the occurrence of an unwanted event and the likelihood of the occurrence of the event”, the risk analysis process outlined in the standard indicates the need to identify information assets at risk, the potential threats or threat sources, the potential vulnerabilities and the potential consequences (impacts) if risks materialize. Examples of threats, vulnerabilities and impacts are tabulated in the annexes; although incomplete, these may prove useful for brainstorming risks relating to information assets under evaluation. It is clearly implied that automated system security vulnerability assessment tools are insufficient for risk analysis without taking into account other vulnerabilities plus the threats and impacts: merely having certain vulnerabilities does not necessarily mean your organization faces unacceptable risks if the corresponding threats or business impacts are negligible in your particular situation.

The standard includes a section and annex on defining the scope and boundaries of information security risk management which should, I guess, are no less than the scope of the ISMS. The standard doesn't specify, recommend or even name any specific method (such as those listed in the ISO27k FAQ), although it does specify a structured, systematic and rigorous method of analyzing risks through to creating the risk treatment plan.

The standard deliberately remains agnostic about quantitative and qualitative risk assessment methods, essentially recommending that users choose whatever methods suit them best, and noting that they are both methods of estimating, not defining, risks. Note the plural - 'methods' - the implication being that different methods might be used for, say, a high-level risk assessment followed by more in-depth risk analysis on the high risk areas. The pros and cons of quantitative vs qualitative methods do get a mention, although the use of numeric scales for the qualitative examples is somewhat confusing.

The steps in the process are (mostly) defined to the level of inputs -> actions -> outputs, with additional “implementation guidance” in similar style toISO/IEC 27002. The standard incorporates some iterative elements e.g. if the results of an assessment are unsatisfactory, you loop-back to the inputs and have another run through. For those of us who think in pictures, there are useful figures giving an overview of the whole process and more detail on the risk assessment -> risk treatment -> residual risk bit.

Managing and measuring risk with ISO 27005

The process of managing information security risk includes many overlapping and poorly differentiated steps (or clauses, to use ISO-speak):

Context establishment
Risk assessment
Risk treatment
Risk acceptance
Risk communication
Risk monitoring and review

What, for example, is the context of risk management if not the sum of all the other steps? Does not communication of risk include monitoring and reviewing? The most aggressively confusing section of ISO 27005 is the one on risk assessment, which includes risk analysis and risk evaluation. Risk analysis in turn is made up of risk identification and risk estimation. Some (but not all) of these terms are defined in the glossary, but in so arbitrary a manner that a perfectly valid alternative approach could use the same terms in a different way or use different terms altogether and still achieve the same objective: managing risk.

Missing from ISO 27005: Risk estimation

What does not appear in the standard is the measurement of risk. It is axiomatic that what cannot be measured cannot be managed. The omission of risk measurement from the standard is significant enough that, whether mentioned or not, it must be performed by anyone seriously attempting to manage risk. Measurement is addressed indirectly by risk estimation, in the same sense that all estimates are measurements of a sort, but not vice versa "About a foot" is not the same as "12 1/2 inches," as anyone who has ever had to cut window glass can testify.

It doesn’t really add anything remarkable or special that we don’t already have in place in any number of other documents and standards. It would seem that its only demonstrative use is for the purposes of auditing to standard compliance. And I have to think that this is really what this document is all about, something more to serve the ISMS and the cottage industry that surrounds it. And that’s a shame, because the field of risk management could really use someone like the ISO really putting forth a significant and good effort.

http://www.iso27001security.com/html/27005.html

TARA (the Threat Agent Risk Assessment)

2011-09-16T16:02:00.000+03:00

TARA (the Threat Agent Risk Assessment) is a relatively new risk-assessment framework that was created by Intel in order to help companies manage risk by distilling the immense number of possible information security attacks into a digest of only those exposures that are most likely to occur. The points here is that it would be prohibitively expensive and impractical to defend every possible vulnerability. By using a predictive framework to prioritize areas of concern, organizations can proactively target the most critical exposures and apply resources efficiently to achieve maximum results.

The TARA methodology identifies which threats pose the greatest risk, what they want to accomplish and the likely methods they will use. The methods are cross-referenced with existing vulnerabilities and controls to determine which areas are most exposed. The security strategy then focuses on these areas to minimize efforts while maximizing effect. Intel says awareness of the most exposed areas allows the company to make better decisions about how to manage risks, which helps with balancing spending, preventing impacts and managing to an acceptable level of residual risk. The TARA methodology is designed to be readily adapted when a company faces changes in threats, computing environments, behaviors or vulnerabilities.

TARA relies on three main references to reach its predictive conclusions. One is Intel's threat agent library, which defines eight common threat agent attributes and identifies 22 threat agent archetypes. The second is its common exposure library, which enumerates known information security vulnerabilities and exposures at Intel. Several publicly available common exposure libraries are also used to provide additional data. The third is Intel's methods and objectives library, which lists known objectives of threat agents and the methods they are most likely to use to accomplish these goals.

A main benefits deriving from TARA is that the threat agent library and the methods and objectives library can be easily used within other risk-assessment methodologies, especially if there is a need to standardize on common threat agents and corresponding methods. TARA appears to be a good tool for identifying, predicting and prioritizing threats against your infrastructure and can be used to create common libraries that can be shared among different groups.

The framework focuses on threats rather than assets, identifying more or less on what bad things can happen. This is both good and bad because by focusing on threats rather than asset value, an assessor may miss the mark in identifying true infrastructure risks. It also seems to make the assumption that the only way to view risk is from the perspective of 'What's the worst thing that could happen?'A drawback of TARA is that only addresses the likelihood of threat events, but doesn't take into account the risk's impact. Another drawback of the framework is that it's new and untested. It is not very common and not widely used as a single risk management methodology but usually in conjunction with other framework.

TARA also appears to be yet another qualitative methodology rather than one that can be used for quantitative analysis.

NIST RMF (National Institute of Standards and Technology's Risk Management Framework)

2011-09-15T12:46:00.001+03:00

The NIST RMF (National Institute of Standards and Technology's Risk Management Framework) described here comprises a mature process that has been applied in the field of risk management for almost ten years. This RMF is mostly designed to manage software-induced business risks. Through the application of five simple activities, analysts use their own technical expertise, relevant tools, and technologies to carry out a reasonable risk management approach.

The purpose of an RMF like this is to allow a consistent and repeatable expertise-driven approach to risk management. Progressing on and description of the software risk management activities in a consistent manner, the basis for measurement and common metrics emerges. Such metrics are sorely needed and should allow organizations to better manage business and technical risks given particular quality goals; make more informed, objective business decisions regarding software and improve internal software development processes so that they in turn better manage software risks.

1. Five Stages of Activity

The RMF consists of the five fundamental activity stages:

Understand the business context.

Identify the business and technical risks.

Synthesize and prioritize the risks, producing a ranked set.

Define the risk mitigation strategy.

Carry out required fixes and validate that they are correct.

NIST RMF also outlines a series of activities related to managing organizational risk. These can be applied to both new and legacy information systems, according to the NIST.

The activities include:

· Categorizing information systems and the information within those systems based on impact.

· Selecting an initial set of security controls for the systems based on the Federal Information Processing Standards (FIPS) 199 security categorization and the minimum security requirements defined in FIPS 200.

· Implementing security controls in the systems.

· Assessing the security controls using appropriate methods and procedures to determine the extent to which the controls are implemented correctly, operating as intended and producing the desired outcomes with respect to meeting security requirements for the system.

· Authorizing information systems operation based on a determination of the risk to organizational operations and assets, or to individuals resulting from the operation of the systems, and the decision that this risk is acceptable.

· Monitoring and assessing selected security controls in information systems on a continuous basis, including documenting changes to the systems, conducting security-impact analyses of the associated changes, and reporting the security status of the systems to appropriate organizational officials on a regular basis.

One of the primary strengths of RMF is that it was developed by the NIST, which is charged by Congress with ensuring that security standards and tools are researched, proven and developed to provide a high level of information security infrastructure. Because government agencies and the businesses that support them need their IT security standards and tools to be both cost-effective and highly adaptable, the framework is constantly being reviewed and updated as new technology is developed and new laws are passed. Furthermore, independent companies have developed tools that support the NIST standards, knowing that the basis for applications is stable; software development companies are more willing to develop application tools to support the framework. The model also helps companies determine when something exceeds a certain threshold of risk.

As for weaknesses, like any of these frameworks, you have to make sure that the people who are doing the risk assessment have the discipline to input reasonable data into the model so you get reasonable data outputs. After all, you cannot manage what you cannot measure and most of all, what you cannot see. Additionally, since it is not an automated tool but a documented framework, meaning that it apart from input and output dependencies, it has to do with people’s aspirations that sometimes are quite more subjective.

To sum up, the activities of identifying, tracking, storing, measuring, and reporting software risk information cannot be overemphasized. Successful use of the RMF depends on continuous and consistent identification and storage of risk information as it changes over time. A master list of risks should be maintained during all stages of RMF execution and continually revisited. Measurements regarding this master list make excellent reporting information. For example, the number of risks identified in various software artifacts and/or software life-cycle phases can be used to identify problematic areas in software process. Likewise, the number of software risks mitigated over time can be used to show concrete progress as risk mitigation activities unfold. Links to descriptions or measurements of the corresponding business risks mitigated can be used to clearly demonstrate the business value of the software risk mitigation process and the risk management framework.

FAIR (Factor Analysis of Information Risk)

2011-09-10T16:12:00.002+03:00

FAIR (Factor Analysis of Information Risk) is a framework for understanding, analyzing and measuring information risk. Information security practices to date have generally been inadequate in helping organizations effectively manage information risk since there is a heavy reliance on practitioner intuition and experience. While these are valuable, they don't consistently allow management to make effective, well-informed decisions.

FAIR is designed to address security practice weaknesses. The framework aims to allow organizations to speak the same language about risk; apply risk assessment to any object or asset; view organizational risk in total; defend or challenge risk determination using advanced analysis; and understand how time and money will affect the organization's security profile.

The FAIR vernacular allows IT people and the business lines to talk about risk in a consistent manner. One of the advantages of the framework is that it doesn't use ordinal scales, such as one-to-10 rankings, and therefore isn't subject to the limitations that go with ordinal scales, for example, 'high, medium and low' is an example of an ordinal scale, as is 'red, yellow and green' and 'one, two and three. Imagine what the result will be if you add or multiply two medium values, or add or multiply yellow plus green. It will definitely have no meaning at all, yet we see many risk calculations in our industry that do exactly that when they use addition and/or multiplication with numeric ordinal scales.

FAIR uses dollar estimates for losses and probability values for threats and vulnerabilities. Combined with a range of values and levels of confidence, it allows for true mathematical modeling of loss exposures. Another plus is that FAIR has more detailed definitions of threats, vulnerabilities and risks. FAIR has a taxonomy that breaks down the terms on a more granular level. The taxonomy enables describing more easily and credibly how conclusions are made and that they are not based on assumptions but on actual measurable results.

The most important downside of FAIR is the fact that it can be difficult to use and it's not as well documented as some other methodologies.

Basic FAIR analysis is comprised of ten steps in four stages:

Stage 1 – Identify scenario components

1. Identify the asset at risk

2. Identify the threat community under consideration

Stage 2 – Evaluate Loss Event Frequency (LEF)

3. Estimate the probable Threat Event Frequency (TEF)

4. Estimate the Threat Capability (TCap)

5. Estimate Control strength (CS)

6. Derive Vulnerability (Vuln)

7. Derive Loss Event Frequency (LEF)

Stage 3 – Evaluate Probable Loss Magnitude (PLM)

8. Estimate worst-case loss

9. Estimate probable loss

Stage 4 – Derive and articulate Risk

10. Derive and articulate Risk

To sum up FAIR allows organizations to:

· Speak in one language concerning their risk

· Be able to consistently study and apply risk to any object or asset

· View organizational risk in total

· Defend or challenge risk determination using an advanced analysis framework.

· Understand how time ad money will impact security profile

OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation)

2011-09-04T16:24:00.000+03:00

OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation), developed at the CERT Coordination Center at Carnegie Mellon University, is a suite of tools, techniques and methods for risk-based information security strategic assessment and planning.OCTAVE defines assets as including people, hardware, software, information and systems. There are three models, including the original, which CERT says forms the basis for the OCTAVE body of knowledge and is aimed at organizations with 300 or more employees; OCTAVE-S, similar to the original but aimed at companies with limited security and risk-management resources; and OCTAVE-Allegro, a streamlined approach to information security assessment and assurance.

The framework is founded on the OCTAVE criteria—a standardized approach to a risk-driven and practice-based information security evaluation. These criteria establish the fundamental principles and attributes of risk management. The OCTAVE methods have several key characteristics. One is that they're self-directed: Small teams of personnel across business units and IT work together to address the security needs of the organization. Another is that they're designed to be flexible. Each method can be customized to address an organization's particular risk environment, security needs and level of skill. A third is that OCTAVE aims to move organizations toward an operational risk-based view of security and addresses technology in a business context.

Among the strengths of OCTAVE is that it's thorough and well documented, the people who put it together are very knowledgeable, and it's been around a while and is very well-defined and freely available. Because the methodology is self-directed and easily modified, it can be used as the foundation risk-assessment component or process for other risk methodologies. The original OCTAVE method uses a small analysis team encompassing members of IT and the business. This promotes collaboration on any found risks and provides business leaders [with] visibility into those risks. To be successful, the risk assessment-and-management process must have collaboration. In addition, OCTAVE looks at all aspects of information security risk from physical, technical and people viewpoints, If you take the time to learn the process, it can help you and your organization to better understand its assets, threats, vulnerabilities and risks. You can then make better decisions on how to handle those risks.

Experts say one of the drawbacks of OCTAVE is its complexity and the fact that it doesn't allow organizations to mathematically model risk makes it a clearly a qualitative methodology.

Risk Management Methods and Frameworks Part III

2011-08-28T14:16:00.003+03:00

The Risk Management as a continuous process

Risk management is a continuous process. That is, identifying risks only once during a project is insufficient. The idea of "crossing off" a particular stage once it has been executed and never doing those activities again is incorrect. Though the five stages are represented in a particular serial order, they may need to be applied over and over again throughout a project, and their particular ordering may be interleaved in many different ways.

Risk management should be a continuous and developing process which runs throughout the organization’s strategy and the implementation of that strategy. It should address methodically all the risks surrounding the organization’s activities past, present and in particular, future.

It must be integrated into the culture of the organization with an effective policy and a program led by the most senior management. It must translate the strategy into tactical and operational objectives, assigning responsibility throughout the organization with each manager and employee responsible for the management of risk as part of their job description. It supports accountability, performance measurement and reward, thus promoting operational efficiency at all levels.

The Risk Management Frameworks

Assessing and managing risk is a high priority for many organizations, and given the turbulent state of information security vulnerabilities and the need to be compliant with so many regulations, it's a huge challenge. Several formal IT risk-assessment frameworks have emerged over the years to help guide security and risk executives through the process. These include:

Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE)
Factor Analysis of Information Risk (FAIR)
The National Institute of Standards and Technology's (NIST) Risk Management Framework (RMF)
Threat Agent Risk Assessment (TARA)
ISO/IEC 27005
CCTA Risk Analysis Management & Methodology (CRAMM)

Here's a look at these key frameworks and some of their strengths and weaknesses, with emphasis on input from those who have used them in real-world settings. The information in clearly indicative and does not suggest that these frameworks are the only and best ones. In many cases people have also used hybrid of two and sometimes three of these frameworks to manage their risks. What makes that a valuable technique is the simultaneous use of qualitative and quantitative frameworks to leverage results to the best possible outcome.

Risk Management Methods and Frameworks Part II (continued)

2011-08-16T16:06:00.006+03:00

3. Analyze risks

Identify the controls (currently in place) that deal with the identified risks and assess their effectiveness. Based on this assessment, analyse the risks in terms of likelihood and consequence. Refer to the Risk Matrix to assist you in determining the level of likelihood and consequence, and the current risk level (a combination of likelihood and consequence). Large numbers of risks will be apparent in almost any given system. Identifying these risks is important, but it is the prioritization of these risks that leads directly to creation of value. Synthesis and prioritization should be driven to answer questions such as "What shall we do first given the current risk situation?" and "What is the best allocation of resources, especially in terms of risk mitigation activities?" Clearly, the prioritization process must take into account which business goals are the most important to the organization, which goals are immediately threatened, and how likely technical risks are to manifest themselves in such a way as to impact the business. This stage creates as its output a list of all the risks and their appropriate priority for resolution. Typical risk metrics include, but are not limited to, risk likelihood, risk impact, risk severity, and number of risks emerging and mitigated over time.

The analysis stage assigns each risk a significance rating taking into account any existing factors which will operate to control the risk. For simple risk statements, where the risk can be expressed as an uncertain event, this can be accomplished with qualitative impact and likelihood scales and a matrix defining the significance of various combinations of these. Where risks are complex in themselves, possibly involving several related events and influences, some form of modelling may be necessary. No matter how risks are described in detail, the outcome of this stage is an initial view of the significance of the identified risks. It is recognised that, particularly with simple scoring schemes, risks can be honestly assigned too high or too low a significance on the first pass. The next stage is designed to review this assignment and adjust it where necessary.

4. Evaluate risks

This stage of the risk assessment process determines whether the risks are acceptable or unacceptable. This decision is made by the person with the appropriate authority. A risk that is determined as acceptable should be monitored and periodically reviewed to ensure it remains acceptable. A risk deemed unacceptable should be treated. In all cases the reasons for the assessment should be documented to provide a record of the thinking that led to the decisions. Such documentation will provide a useful context for future risk assessment. Where there are only a few risks at work, the evaluation stage might be relatively light weight. However, in complex situations and where there are many risks to consider, it is a crucial step towards achieving an agreed view of the relative importance of the identified risks. Evaluation takes the initial analysis and reviews it against the organisation’s known priorities and requirements. Any risks which have been accorded too high or too low a significance are adjusted, with a record of the fact being retained for tracing purposes. It is common to find a large number of minor risks being identified, and during evaluation these can be removed from the process, after due consideration. This screening avoids the process being bogged down by the sheer volume of information it can generate.

5. Determine the treatments for the risks

Treatment strategies will be directed towards:

a) Avoiding the risk by discontinuing the activity that generates it, (rarely an option when providing services to the public),

b) Reducing the likelihood of the occurrence,

c) Reducing the consequences of the occurrence,

d) Transferring the risk, and

e) Retaining the risk.

Potential treatment options are developed according to the selected treatment strategy. The selection of the preferred treatment options takes into account factors such as the costs and effectiveness. The determination of the preferred treatments also includes the documentation of implementation details (eg responsibilities, a timetable for implementation and monitoring requirements). The intention of these risk treatments is to reduce the risk level of unacceptable risks to an acceptable level (ie: the target risk level). Use the Risk Matrix to determine the expected reduction in level of risk (expected consequence, likelihood and Target risk level) resulting from the successful implementation of the treatment. Given a set of risks and their priorities from stage three, the next stage is to create a coherent strategy for mitigating the risks in a cost effective manner. Any suggested mitigation activities must take into account cost, time to implement, likelihood of success, completeness, and impact over the entire corpus of risks. A risk mitigation strategy must be constrained by the business context and should consider what the organization can afford, integrate, and understand.

Risk treatment consists of determining what will be done in response to the identified risks. Any plans which were in place before the risk management process began, are augmented with measures to deal with risks before they arise and contingency plans with which to recover if a risk comes to pass. In addition to these supplementary plans, treatment might also include alteration of the base plans of an organisation. Occasionally the best way to treat a risk might be to adopt an alternative strategy all together, to avoid a risk or make the organisation less vulnerable to its consequences. There is a final step in the risk management process that is not identified in the actual process but it is more of continues process joining and maintaining step. Some methodologies though suggest it is a formal step of the whole process.

Monitoring and review

There are two levels of the monitoring and review step of the process. The outputs of the other five steps should be monitored and reviewed as times progresses. The original assessment might be out of date if variables of the environment change. However, there is not necessary to run the whole process over and over again just only the steps that are required to update the changes made. The second part of the process is the monitoring step, which is the monitoring of the output of the other five steps. The execution of the risk management process absorbs resources and must be managed to ensure it is cost effective.

Risk Management Methods and Frameworks Part II (continued)

2011-05-29T18:42:00.002+03:00

The steps involved in managing risk are:

1. Establish Goals and Context

As outlined in the Risk Management process, the risk assessment is undertaken within the context of your goals. The identification / validation of your goals is therefore a critical first step in the risk management process.

Effective risk management requires a thorough understanding of the context in which your company, department or Agency operates. The analysis of this operating environment enables you to define the parameters within which the risks to your outputs need to be managed.

The context sets the scope for the risk management process. The context includes strategic, organizational and risk management considerations. According to the international Standards and best practices strategic context defines the relationship between the organizations and its environment. Factors that influence the relationship include financial, operational, competitive, political (public perceptions / image), social, client, cultural and legal. The definition of the relationships is usually communicated through frameworks such as the SWOT (Organizational strengths, weaknesses, opportunities and threats) and PEST (Political, Economic, Societal, and Technological).

The organizational context provides an understanding of the organization, its capability and goals, objectives and strategies. According to International Standards and best practices, organizational context is important because:

a) risk management occurs within the context of endeavoring to achieve the goals and objectives,

b) failure to achieve the objectives is one set of risks that need to be managed, and

c) the goals and strategies assist to define whether a risk is acceptable or unacceptable.

The risk management context defines that part of the organization (goals, objectives, or project) to which the risk management process is to be applied.

2. Identify Risks

Identify the risks most likely to impact on your outputs, together with their sources and impacts. It is important to be rigorous in the identification of sources and impacts as the risk treatment strategies will be directed to sources (preventive) and impacts (reactive).

Business risks directly threaten one or more of a customer's business goals. The identification of such risks helps to clarify and quantify the possibility that certain events will directly impact business goals. Business risks have impacts that include direct financial loss, damage to brand or reputation, violation of customer or regulatory constraints, exposure to liability, and increase in development costs. The severity of a business risk should be expressed in terms of financial or project management metrics. These include, but are not limited to, market share (%), direct cost, level of productivity, and cost of rework.

Business risk identification helps to define and steer use of particular technical methods for extracting, measuring, and mitigating software risk given various software artifacts. The identification of business risks provides a necessary foundation that allows software risk (especially impact) to be quantified and described in business terms.

The key to making risk management work for business lies in tying technical risks to business context in a meaningful way. The ability to identify and deeply understand risks is thus essential. Uncovering and recognizing technical risks is a high-expertise undertaking that usually requires years of experience.

Risk Management Methods and Frameworks Part II

2011-03-30T12:50:00.004+03:00

Risk Management Framework

A continuous risk management process is a necessary part of any approach to Information security. Information security risk includes risks found in artifacts during assurance activities, risks introduced by insufficient process, and personnel related risks. A risk management framework is an essential philosophy for approaching security work. Following the risk management framework introduced here is by definition a full life-cycle activity. For the purposes of this description, consider risk management a high-level approach to iterative risk analysis that is deeply integrated throughout the system development life cycle.
This Risk Management Framework described here is a mixed version of the both qualitative and quantitative frameworks combined to create a more open framework that includes advantages and excludes disadvantages of qualitative and quantitative approaches. This is accomplished through the application of five simple stages, relevant technical expertise, tools, and technologies that produce a reasonable risk management approach.

Risk Management Framework Stages

This Risk Management Framework consists of the five fundamental stages shown in Figure 1:

1.Establish the business context and goals
2.Identify the business risks.
3.Analyze and prioritize the risks.
4.Evaluate the risks.
5.Define the risk treatment strategy.

Figure 1

Preceding the five stages we also have an activity that cannot be omitted from the approach. Above the afore mentioned five stages we introduce the communicate and consult activity. Consultation and communication are both key components of the risk management process and a major beneficial side effect. Successful risk management relies on achieving a high level of creative input and involving all parties with a role to play in achieving a successful outcome for the project or business process being addressed. In both the planning and execution of the risk management process, it is important to ensure that all those who need to be involved are given adequate opportunity to do so and are kept informed of developments in the understanding of risks and the measures taken to deal with them.

Following the five steps of this Risk Management Framework is another activity that includes monitoring and reviewing the success of the treatment process and take the necessary actions to sustain this status. There are two levels to the underlying monitoring and review component of the process. The outputs of the other five stages must be kept under review as time moves on. Changes in the environment or simply the discovery of better information might make the original assessment out of date. It is not generally necessary to begin the whole process over again when this happens, unless the change is significant, but those parts which are directly affected by changing circumstances must be brought up to date. The second component of this part of the process, is the monitoring of the operation of the other five stages. The execution of the risk management process absorbs resources and must be managed to ensure that it is conducted cost-effectively.

Risk Management Methods and Frameworks Part I

2011-02-08T23:36:00.016+02:00

Risk and Vulnerability Assessment Services

In the international business environment, where decision-making follows a risk-based approach and business efficiency relies on the right balance, Information Security risk assessment is essential.

Risk Assessment services provide focus on identifying the threats and vulnerabilities regarding the security of corporate information, evaluating their potential impact on the business and recommending the appropriate mitigation controls to manage the risk. Risk and vulnerability management services provide organizations with the preventative, detective, and corrective measures needed to help limit the frequency and impact of security incidents.

Risk and vulnerability assessment can help management in decision making on Information Security, regarding the evaluation of policies effectiveness, and the selection of cost-effective mitigation controls to manage the risk of potential harm. Assessing organization's current security state is an integral step to securing sensitive data and meeting regulatory requirements.

Corporate Information Security Risk Assessment

Complete Information Security Risk Assessment using a structured methodology, best practices and strong quality procedures, involving the entire corporate environment. This service provides an assessment, which examines the level of security provided by the majority of information systems, networks, and applications.

Security Risk Assessment focuses on assisting organization's to detect any security weaknesses and sensitive spots of critical systems in the network. It also examines the effectiveness and completeness of Information Security controls (either technical or procedural). Security experts provide a thorough analysis of the organization's current security state, based on the globally-recognized ISO 27001 standard and industry best practices and a specific actionable plan to improve overall security posture based on the business needs.

Information Security Management Framework Implementation

The design and implementation of the organization’s Information Security framework including the relevant policies, standards, procedures, guidelines and organizational structures, as well as the determination of controls requirements, must be adequate enough to enforce the required level of Information Security, throughout the organization.

Organizations can take advantage standards and best practices, in order to implement the required Information Security infrastructure leading to the achievement of the organization’s desirable level of security. The significance and the level of protection required, depends on the nature and value of the corporate information.

This framework results in the establishment and enforcement of an effective Information Security Management System that safeguards information against unauthorized use, disclosure, modification, damage or loss.