tropos: risk analysis · natural disaster) and composite ... defect detection and prevention ... cy...

Tropos: Risk Analysis

Paolo Giorgini Department of Information and Communication Technology University of Trento - Italy http://www.dit.unitn.it/~pgiorgio

Agent-Oriented Software Engineering course Laurea Specialistica in Informatica

A.A. 2009-2010

© P. Giorgini

Outline

  What is RISK?   Risk in Security   Security and Dependable Framework   Risk Framework   Tropos Goal-Risk Framework

  Modeling   Reasoning/Analysis   Tools

  Conclusion and Remarks

© P. Giorgini

Event

 What is event  something that happens at a given place and time  case (a special set of circumstances)

•  it may rain in which case the picnic will be cancelled  a phenomenon located at a single point in space-time

•  the fundamental observational entity in relativity theory  consequence, effect, outcome, result, event, issue,

upshot (a phenomenon that follows and is caused by some previous phenomenon)‏ [WordNet 3.0 http://wordnet.princeton.edu]

© P. Giorgini

Uncertainty

  What is uncertainty   Impreciseness

•  Today is warm   Lack of knowledge

•  I think a wrestler is stronger than a karateka   Variability

•  Tossing a coin or throw a dice   Likelihood

•  It is likely if tomorrow it will be rain •  Likelihood can be reduced into lack of knowledge and variability

[T. Bedford and R. Cooke, Probabilistic Risk Analysis: Fundations and Methods, Cambridge University Press, 2001]

© P. Giorgini

Uncertainty Theory   Mathematical models

  Probability Theory

  Possibility Theory/Fuzzy Set

  Evidence Theory

  …

€

P(A) ≥ 0;P(X) =1;P(A∪ B) = P(A) + P(B);P(A) + P(A) =1

))(),(()(;1)(;0)( BPAPMaxBAPXPAP =∪=≥

€

m(A) ≥ 0;m(X) ≤1; P(A) =1A∈2X∑ ;P(A) + P(A) ≤1

© P. Giorgini

Failure – Error - Fault   Failure - an event that occurs when the delivered service deviates from

correct service   Error – the deviation from the correct service   Fault - The adjudged/hypothesized cause of an error

•  internal or external of a system •  vulnerability, i.e., an internal fault that enables an external fault to harm the system, is

necessary for an external fault to cause an error and possibly subsequent failures

Causal Chain of Threats

[A.Avizieni et al., IEEE TDSC 2004]

Activation Propagation

© P. Giorgini

Threat - Vulnerability   Threat - circumstance that has the potential to cause

loss or harm   Vulnerability - weakness in the security system   Attack – external malicious event

Causal Chain of Threats

Intrusion Error Failure

I Vulnerability

Attack

Hacker

Hacker Administrator User

V

A

[MAFTIA 2002]

© P. Giorgini

Hazard  Hazard

 any real or potential condition that can cause injury, illness, or death to personnel; damage to or loss of a system, equipment or property; or damage to the environment [US-DoD MIL-STD-882]

 Condition, event, or circumstance that could lead to or contribute to an unplanned or undesirable event [US FAA Order 8040.4 ]

© P. Giorgini

What is Risk ?   Risk is an uncertain event that leads negative

consequences   Risk analysis tries to answer:

  What can go wrong?   How likely is it to happen?   What are the consequences of going wrong?   What is the confidence in the answers to each of the previous

questions? [T. Bedford and R. Cooke, Probabilistic Risk Analysis: Fundations and Methods, Cambridge University Press, 2001]

© P. Giorgini

What are the differences ?   Hazard – no likelihood   Vulnerability – no likelihood   Threat + Vulnerability –assessed using risk notion

© P. Giorgini

Security  High Level Objectives

 Confidentiality is the concealment of information or resources

  Integrity refers to the trustworthiness of data or resources, and it is usually phrased in terms of preventing improper or unauthorized change

 Availability refers to the ability to use the information or resource desired

 Non Repudiation ensures that a contract cannot later be denied by either of the parties involved.

© P. Giorgini

Security Engineering Framework  UML Based

 Abuse Case  Misuse Case  SecureUML  UMLSec

 Requirement Engineering Based  KAOS – Obstacle, Anti-goal   i* - Attacker/Vulnerability Analysis  Secure Tropos

© P. Giorgini

Abuse Case

© P. Giorgini

Misuse Case

© P. Giorgini

KAOS

[A. van Lamswerdee, Elaborating Security Requirements by Construction of Intentional Anti-

Models, ICSE 2004]

[A. van Lamswerdee, E. Latier, Handling Obstacles in Goal-Oriented Requirements

Engineering, TSE 2000]

Anti-Goal

Obstacle

© P. Giorgini

i* approach

[Liu et al., Security and Privacy Requirements Analysis within a Social Setting, RE-03]

© P. Giorgini

Secure Tropos

[N. Zannone, Course material of « Security Requirement Engineering »]

© P. Giorgini

HAZOP - Safety and Reliability Engineering   Objectives

  identify possible deviations from normal operations   ensure that appropriate safeguards are in place to help prevent

accidents   Steps:

  Hazard Identification: use special adjectives-guide words •  e.g., "more," "less," "no," etc. combined with process conditions •  e.g., speed, flow, pressure, etc. to systematically consider all credible deviations from normal conditions

  Evaluate consequences/effects   Assess the adequacy safeguards

© P. Giorgini

HAZOP

© P. Giorgini

HAZard and OPerability   Require relatively fix SOPs (Standard Operating

Procedures) or well defined system.   the identification process of deviations is done by applying guide

words to the system definitions   once the system definitions are changed the deviation could be

not valid anymore or turn to other deviations   Needs multidisciplinary experts and time consuming

  experts need to apply all guide words to system parameters and explore all possible deviations of the normal operation of system.

  More concentrate to the occurrence of single fault/error that could lead to the system deviation and consequently the failure of system

© P. Giorgini

HAZOP

What is the missing concept in those frameworks?

quantificatio

n values (especially likelihood)

We cannot distinguish likely event and unlikely events

© P. Giorgini

FMEA/FMECA  developed in 50ʼs by reliability engineers to

determine problems that could arise from the failure of military system [MIL-STD-1692A]

 Objectives  considers how the failure modes of each system

component can result in system performance problems

 ensures that appropriate safeguards against such problems are in place

© P. Giorgini

FMEA/FMECA  Steps:

 Define the system  Define problem of interests of the system  Decompose the system into smaller elements   Identify potential failure modes of each element of the

system  Evaluate each potential failure mode against the

problem of interest of the system •  effects, causes, likelihood and severity of the failure mode •  probability of the fail of countermeasures in mitigating the

failure mode

© P. Giorgini

FMEA/FMECA

  Failure Mode is prioritized based on the Risk Priority Number RPNFM = LikelihoodFM * SeverityFM * ProbabilityCM

  Deviations from normal operations that do not produce infrastructure failure usually are overlooked.

  Could not model the system failure that is caused by external events (e.g., natural disaster) and composite failures

© P. Giorgini

Reliability Block Diagram   allows reliability block diagram analyses to be performed in a

system   Each block represent a reliable component that constructs the

system

Reliabilitysys=[1-(1-REth0)(1-REth1)]*Rpower

Eth0

Eth1

Power

© P. Giorgini

FTA   Determine combinations hardware-software failures and

human errors that lead to the undesired events/failures (called top events)‏

  Failure is refined it into more detail events and end up with un-develop/external events (called leaf events).

  Refinement is done by modeling the logical relationships among infrastructure failures, human errors, and external events that could lead to the system failure.

  The logical relationship is represented by several types   e.g. OR, AND, XOR, Priority-AND

© P. Giorgini

FTA

  Minimal cut-set is minimal leaf events that could lead to the occurrence of system failure, then to assess likelihood of the system failures/top events can be calculated based on likelihood of leaf events

  Probability of a top-level event can be calculated following the corresponding set-operator to the logic gates

© P. Giorgini

Risk Analysis Baseline   Risk Identification

  Given the objective what kind of risk that can effect   Risk Qualification and Quantification   Risk Evaluation   Risk Controlling   Implementing Risk Strategy   Communicating to the stakeholders

[David Vose, Risk Analysis, 2nd Edition, Willey]

© P. Giorgini

Enterprise Risk Management   developed by PricewaterhouseCoopers and Committee

of Sponsoring Organizations of the Treadway Commission (COSO)‏

  Process that:   is effected by every people at every layer of the enterprise   is applied in strategy setting and across the enterprise   i

s designed to identify potential events that may affect the enterprise

  manages the risk to be within the enterprise risk appetite   provides

reasonable

[COSO, Enterprise Risk Management – Integrated Framework, Sept 2004]

© P. Giorgini

Enterprise Risk Management   three dimensions

 achievement of objectives, components of ERM, and entities

  Objective Category   Strategic – relating to high-level

goals, aligned with and supporting the entityʼs mission

  Operations – relating to effective and efficient use of the entityʼs resources

  Reporting – relating to the reliability of the entityʼs reporting

  Compliance – relating to the entityʼs compliance with applicable laws and regulations

© P. Giorgini

Enterprise Risk Management   ERM Component

  Internal Environment   Objective Setting   Event Identification   Risk Assessment   Risk Response   Cost and benefit of potential risk responses;   Possible opportunities lose, once risk

responses are applied.   Control Activities   Information and Communication   Monitoring

© P. Giorgini

CORAS

  Research and technological development project under Information Society Technologies (IST)‏

  Objectives   developing a framework for risk analysis of security critical systems

  Able to work with several analysis tools   e.g., FMECA, FTA, HAZOP

  risk management steps:   Context Establishment, by selecting usage scenarios of the system;   Risk Identification, which

tries to identify the threats based of scenarios and the vulnerabilities of these assets;

  Risk Estimation, which assigns the values (impact and likelihood of occurrence) to identified threats;

  Risk Evaluation, which identifies the risk level of each threat;   Risk Treatment, which addresses the treatment of considered threats.

© P. Giorgini

CORAS

Risk Identification identify the threats based of scenarios and the

vulnerabilities of these assets

© P. Giorgini

CORAS Risk Estimation

assign the values (impact and likelihood of occurrence) to identified threats

© P. Giorgini

CORAS Risk Evaluation

identify the risk level of each threat

© P. Giorgini

CORAS

Risk Treatment address the treatment of considered threats

© P. Giorgini

Defect Detection and Prevention   Developed and applied in JPL

and NASA   Consist of three layers model

  Objective - thing that the system has to achieve

  Risk – any kind of thing that, once occur, lead to the failure of objectives achievement

  Mitigations - action that can be applied to reduce the risks

  Relations •  Impact (risk – objective) - quantitative representation of objective lost once the risk occurs •  Effect (mitigation – risk) - quantitative representation of risk reduction if the mitigation is applied

© P. Giorgini

Defect Detection and Prevention   An objective has a weight to represent its importance   A risk has a likelihood of occurrence   Mitigation has a cost for accomplishment   Specify how to compute the level of objectives

achievement and the cost of mitigations   This calculation allows us to evaluate the impact of the

taken countermeasures and thus supports the decision making process.

  Able to work together with other quantitative tools   e.g. FMECA, FTA

to model and assess risk/failure

© P. Giorgini

Tropos Goal Model   Represent strategic

dependency and rationale among actors/stakeholders in a system

  What we can get:   Incorporate organization setting

analysis and system-to-be analysis during software development process

  Refinement of the top goal   Relation among goals (e.g., positive, negative)‏   Dependency among actors

•  Delegation + Trust in Secure Tropos   Alternative to achieve the goal

•  Choose the most “appropriate” (e.g., cheap) alternative

© P. Giorgini

Tropos Goal Model   What is missing:

  There is un-control thing that can effect to the goal model   Nothing is certain   The cheapest can correspond to the most risky alternative   Introducing a countermeasure can be seen a requirement

revision •  May require to redo requirement analysis again

  It would be nice:   Taking into account “uncertain” events (especially risks) while

requirement elicitation   Requirements has already encompass stakeholdersʼ intentions

and necessary countermeasures to treat relevant risks

© P. Giorgini 42

Risk in TROPOS view   Current SE approaches

  Risk is analyzed when requirements have been elicited   Problem

1.  Elicited requirements are too risky to be fulfilled once they are implemented 2.  Some requirements are error-prone 3.  Safeguards, for (1), can obstruct the fulfillment of other requirements

Providing a formal framework to:   Elicit requirements that has considered risks during the analysis   Consider stakeholdersʼ mental-state (e.g., preferences, risk-appetite, trust, etc.)

while requirement analysis   Manage risk in the organizational-level (not just the technical-system)

Tropos Goal-Risk Framework

RISK is the combination of the probability of an event and its consequence

[ISO Guide 73: 2002]

© P. Giorgini 44

Goal-Risk Framework   Underlain Framework

  Tropos Goal Model   Defect Detection and Prevention [Feather 2001]

  GR-Framework   Modeling

•  Constructs: Goals, Tasks, Resource, Event •  Relation: Decomposition, Contribution, Means-End, Impact,

Alleviation   Reasoning/Analysis Mechanisms   Process   Tool

© P. Giorgini 45

Tropos Goal-Risk concepts   Basic concepts

  Goal (and Softgoal) – intention of stakeholder that needs to be satisfied

  Tasks – a course of actions that is meant to satisfy goal, to produce resource, or to treat event

  Resource – artifact that is needed to execute task or to satisfy goal.

  Event – uncertain circumstance that affect to the goal satisfaction (directly or indirectly)

© P. Giorgini 46

Goal-Risk Modeling   Consists of three conceptual

layers:   Goal – “thing” that need to be

achieved   Event – “uncertain

circumstance” that affect the goal layer

  Treatment – measures to treat events

© P. Giorgini 47

GR properties   Properties

  SAT/DEN– number of evidence a construct is satisfied/denied

  Likelihood of an event occurs

  Cost to execute a task or to provide a resource

  Loss to be resulted in case the failure of fulfilling a goal

SAT DEN Likeli-hood

Cost Loss

Goal X X X Task X X X Resource X X X Event X X X

© P. Giorgini 48

GR Relations (1)   Relation

  Decomposition – to model a construct refinement or to model an alternative

  Contribution – to model influence a construct to another

  Means-End – to model the means to satisfy the end

© P. Giorgini 49

GR Relations (2)

  Impact – to model the severity of an event impact over the goal layer (i.e., goals, tasks, resources)

  Alleviation – to model the mitigation of negative impact of an event

© P. Giorgini 50

GR models   Advantage

  Able to capture RISK (event with negative impact) and OPPORTUNITY (event with positive impact)

  Operate using qualitative-quantitative data and subjective-objective data

  Limitation   no representation to capture the time aspect

© P. Giorgini 51

Goal-Risk Analysis   Requirements = realize stakeholdersʼ goals +

to mitigate risks   Assess the risk-level of requirements   Reason to elicit the best requirements

•  The cheapest requirements (adapt from the Goal Model Reasoning)

•  The reliable (high probability of success) requirements •  The requirements with the lowest “expectancy loss”

  Define treatments to deal with risks

© P. Giorgini 52

Formalization – Impact Relation   It is adapted from the Goal Model

  SAT/DEN: Full>Partial>None (qualitative)   Likelihood: Likely>Occasionally>Rare>Unlikely   Event likelihood is calculated on the basis of SAT and DEN

Sat(E)⊕Den(E)=λ(E)   An Example:

  In case Sat(E)=F and Den(E)=P, then λ(E)=O

© P. Giorgini 53

Formalization – Impact Relation   Event as Risk

  Introduce new evidence for the denial   Event as Opportunity

  Introduce new evidence for the satisfaction

_ _

Enlarge Market Coverage

New Competitors

Motivate for Innovation

+

Opportunity

Risk FS PD

λ(E)=O

FS

PD

NS

PS

ND

ND

ND

FS

© P. Giorgini 54

Formalization for Mitigation   Contribution is used to reduce the likelihood event (by

adding DEN)

  Alleviation is used to mitigate the severity of an event

Employee Training _

Mis-entry

FS ND

FS ND

FS PD

λ(E)=L

λ(E)=O

_ _

Verify Loan Application

Mis-entry

Implement Dual-Verification

_ _


Mis-entry

© P. Giorgini 55

Risk Assessment   Define threshold of risk-

acceptance   Define the alternative

solution to achieve the top goal

  Malicious events can occur and obstruct goals

  Treatment needs to be adopted   to reduce the likelihood of risk   to mitigate the impact of risk

Employee Training

_


_

_ _

Handle Loan Originating Process


Evaluate Loan Application

Approve Loan Application

AND

OR

Assessed by Credit Bureau

Assessed by In-house

Bob (Loan Managers)

++ _ _

Alice (Finance Managers)

Minimize Expenses


Assessed by In-house

Evaluate Loan Application






Approve Loan Application

Mis-entry

© P. Giorgini 56

Notice !!   Treatment can produce negative side effect to the other

goal   Reduction of Expectancy Loss greater than Additional Cost   Reduction of risk greater than negative side effect

_

_ _

Alice (Finance Managers)

Minimize Expenses

Employee Training


Mis-entry

© P. Giorgini 57

Analysis for Eliciting the “Best” Requirement Enumerate

All Alternatives

Choose Some Alternatives

Evaluate an Alternative

Too Risky?

Solution

Enumerate All Possible Treatments

Introduce possible treatments to the alternative

YES

NO

© P. Giorgini 58

Identifying Countermeasures   no guideline to identify countermeasures   an iterative and exhaustive process that stops when

  all risk values are acceptable   the total cost is affordable

  There are five classes of countermeasures:   Avoidance – try to remove the source of risk

•  choose another alternative or drop a particular goals/requirements   Preventive – reduce the likelihood of risks until becoming unlikely

•  employ countermeasures to reduce the likelihood of all leaf-events   Alleviation – reduce the impact of risk in the goal layer

•  adopt countermeasures to mitigate the severity of top-events in obstructing the goal layer

  Detection – reduce the likelihood of risk by mitigating intermediate-events (i.e., events which are not leaf-events nor top-events)

  Attenuation – when the risky event happens •  E.g., recovery actions, buy insurance

© P. Giorgini 60

Risk-based delegation   To satisfy a goal an actor can have multi-choices

  How to choose?   Typically, designers are responsible to elicit and analyze

multi alternative designs   SE methodologies put more emphasis to verify and validate

the final-choice and not to explore possible alternatives   An actor may have different level trust towards

different actors   E.g., Robert trusts Paula and Mark for critical action, but not John

  Very complex problem when a delegated goal is decomposed and further delegated to other actors

© P. Giorgini 61

Possible alternatives

I need to manage air traffic in this sector

Robert

….to manage air traffic means: control current traffic, plan incoming traffic, define sector configuration, and assess the acceptability of sector

Paula

I can plan incoming traffic and assess the acceptability of sector

Luke

I can control current traffic

John

I can plan incoming traffic

I can define sector config. and assess the acceptability of sector

Mark


Trust for Critical

Reliable

Very Reliable

Trust for Critical

Very Reliable

Reliable

Reliable

© P. Giorgini 62

Risk-based selection

I need to manage air traffic in this sector

Robert

….to manage air traffic means: control current traffic, plan incoming traffic, define sector configuration, and assess the acceptability of sector

Paula

I can plan incoming traffic and assess the acceptability of sector

Luke


John

I can define sector config. and assess the acceptability of sector

Mark


Delegate

Reliable

Very Reliable

Delegate

Very Reliable

Reliable

Reliable

I can plan incoming traffic

© P. Giorgini 63

A planning based approach

Requirement Model in terms of

Tropos Model Planner

Planning Axioms

Define Planning Domain: Agents’ Capability Agents’ Trust Possible Decomposition

Goal-Risk Reasoner Too Risky Analyze the

Source of Risks

Tropos Model

Refinement Planning Domain

© P. Giorgini 64

Risk and Trust   Often, we must delegate something to untrustworthy

agents   Different levels of Trust

  Trust, No-Trust, Distrust   E.g., Scott trusts Spencer to control his airspace   Scott believes that Spencer has full evidence to satisfy this goal

  How evidence (SAT/DEN) of a goal is propagated accordingly to the trust level?   Perceived risk   How do trust values change on the base of propagated values?

© P. Giorgini 66

References   Asnar, Y. & Giorgini, P., Modeling Risk and Identifying Countermeasures in

Organizations, CRITIS ʻ06   Asnar, Y. & Giorgini, P., Ensuring Dependability in Socio-Technical System

by Risk Analysis, EDCC ʻ06   Asnar, Y.; Bryl, V. & Giorgini, P., Using Risk Analysis to Evaluate Design

Alternatives, AOSE ʻʼ06   Asnar, Y.; Giorgini, P.; Massacci, F. & Zannone, N.

From Trust to Dependability through Risk Analysis, ARES ʼ07   Asnar, Y.; Giorgini, P. & Zannone, N., Implementing Risk Reasoning in

Jadex Agents, AOSE ʻʼ07   Asnar, Y.; et. Al., Secure and Dependable Patterns in Organizations: An

Empirical Approach, RE ʼ07 (to appear)

tropos: risk analysis · natural disaster) and composite ... defect detection and prevention ... cy...

Documents