tropos: risk analysis · natural disaster) and composite ... defect detection and prevention ... cy...
TRANSCRIPT
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
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
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
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
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
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
_ _
Verify Loan Application
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
_
Implement Dual-Verification
_
_ _
Handle Loan Originating Process
Verify Loan Application
Evaluate Loan Application
Approve Loan Application
AND
OR
Assessed by Credit Bureau
Assessed by In-house
Bob (Loan Managers)
++ _ _
Alice (Finance Managers)
Minimize Expenses
Verify Loan Application
Assessed by In-house
Evaluate Loan Application
Handle Loan Originating Process
Verify Loan Application
Handle Loan Originating Process
Verify Loan Application
Handle Loan Originating Process
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
Implement Dual-Verification
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
I can control current traffic
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
I can control current traffic
John
I can define sector config. and assess the acceptability of sector
Mark
I can control current traffic
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)