TARA (the Threat Agent Risk Assessment)

Posted by Pantazis September 16, 2011 4:02 PM 1 comments

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)

Posted by Pantazis September 15, 2011 12:46 PM 2 comments

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)

Posted by Pantazis September 10, 2011 4:12 PM 1 comments

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)

Posted by Pantazis September 4, 2011 4:24 PM 2 comments

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

Posted by Pantazis August 28, 2011 2:16 PM 0 comments

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)

Posted by Pantazis August 16, 2011 4:06 PM 0 comments

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)

Posted by Pantazis May 29, 2011 6:42 PM 0 comments

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.

Subscribe to: Posts (Atom)