applying a goal-oriented method for hazard analysis: a case study sam supakkul the university of...
TRANSCRIPT
Applying a Goal-Oriented Method for Hazard Analysis:
A Case Study
Sam SupakkulThe University of Texas at Dallas
Lawrence ChungThe University of Texas at
e-commerce system related “hazards”
steal card infoflood system
Adapted from:G. Sindre and A. Opdahl, “Eliciting Security Requirements by Misuse Cases”, TOOLS Pacific 2000E. A. Oladimeji, S. Supakkul, and L. Chung, “Security Threat Modeling And Analysis: A Goal-oriented Approach”, submitted to SEA06
obtain password
server down
unauthorized account disclosure
repudiationspoofing
hazard = an obstacle to product’s goal achievement
Car related “hazards”
theft
paint fading
broken antenna
robbery
driver injury
engine break-down
Challenges for hazard analysis How to represent hazards and countermeasures? How to organize and focus hazards elicitation? How to rationalize and trade-off multiple countermeasures? How to integrate with requirements model?
rusting
Current practice – misuse cases
[G. Sindre and A. L. Opdahl, “Eliciting Security Requirements with Misuse Cases”, Requirements Engineering 2002]
Misuse case threatens use case
Countermeasure use case mitigates misuse case
Real attackers e.g. crook, thief
Imaginary attackerse.g. bad luck, bad weather
Seamlessly integrated with use case model
Interplay between hazards and countermeasures
Equal weight for all hazards
Alternatives and rationale not recorded
Require malicious actor for every hazard
Current practice – fault tree
[D. Lu and R. Lutz, “Fault contribution trees for product families”, ISSRE 2002]
Fault or hazard
Refine hazard with AND/OR decomposition
Hazard relationships through AND/OR decomposition
Only hazards are represented
Independent of requirements model
Detailed hazard
Strategies for meeting the challenges How to represent hazards and countermeasures
Hazard = obstacle to product’s goal achievement
Countermeasure = obstacle to hazard achievement How to organize and focus hazards elicitation
NFR-driven elicitation, focus more on critical NFRs How to rationalize one countermeasure over others
multiple countermeasures per hazard compare by countermeasure’s effectiveness and justification
How to integrate with requirements modelIntegrate with the UML use case model
Adopting the NFR Framework for hazard analysis
Represent NFRs as (soft)goals Identify NFR operationalizations with positive
contribution to achieve NFRs
Extensions to support hazard analysis: Associate NFRs with use case model elements Hazard = NFR operationalization with negative
contribution toward the NFRs countermeasure = operationalization with negative
contribution toward the hazards
Representing NFRs as softgoals in the use case model
Driver
Car
Drive car
Open door
Control car
Security
[Supakkul and Chung, SERA 04]
Convenience
The association provides context for the NFRs
Security of the system (car)
Convenience of the interface
!
! → important NFR!! → critical NFR
Refine NFRs and explore solution alternatives
LockTransmission
++
LockDoor
+
Availability [Car,parking]
Confidentiality [Car,parking]
++
AutoDoorLockManualDoorLock
+
- -
X
Security [Car,parking]Convenience [OpenDoor]
“Driver won’t forget”
++
[J. Mylopoulos and L. Chung 92, L. Chung et. al 2000]
NFR Softgoal
NFR Operationalization
Claim
AND Decomposition
Positive Contribution for possible solutions
1. Refine NFR softgoals2. Explore solution alternatives (operationalization)
4. Make trade-offs analysis and finalize design decisions3. Record arguments “for” or “against” choices and contributions
Naming convention = Type [Topic]Type = Availability, Topic = EMS
Negative contribution for side-effects
!
Hazard analysis process
Control
Car
ParkCar
Driver OpenDoorLockDoor
DriveCar
1. Identify and refine NFRs
3. Identify and refine operationalizations
4. Trade-off analysis
5. NFRs satisficed No
Yes
2. Hazard analysis2.1 Identify and refine hazards
2.2 Identify and refine countermeasuresSecurity
Convenience
perform hazard analysis before the regular NFR operationalization analysis
Reason: some operationalizations are natural countermeasures of some hazards. e.g. LockDoor to counter Theft
LockTransmission[Car,parking]
Security [Car]
Theft [Car,parking]
ControlCar
Car
ParkCar
Driver
LockTransmission
«extend»
«trace»
Confidentiality[Car]
Availability[Car]
-
LockDoor[Car,parking]
-AccessCabin [Car,parking]
StartEngine [Car,parking] DriveOff
[Car,parking]
UseKey[Car,parking]
ShortIgnition[Car,parking]
OpenDoor
Convenience [OpenDoor]
Break-in[Car,parking]
UseDoorRemoteControl [Car,parking]
-
-
-
-
-
-
X
X
X
!
Availability[Car,driving]
Availability[Car,parking]
Hazard analysis for carhazard = operationalization with negative contribution toward NFR
hazard refined with AND-decomposition to detailed hazards
ignition key as a countermeasure to prevent thief from starting the engine
Thief may counter and circumvent by shorting the ignition circuit to start the engine.
Lock transmission to counter the shorting of the ignition.
Traceability between hazards and countermeasures
LockTransmission[Car,parking]
Security [Car]
Theft [Car,parking]
ControlCar
Car
ParkCar
Driver
LockTransmission
«extend»
«trace»
Confidentiality[Car]
Availability[Car]
-
LockDoor[Car,parking]
-AccessCabin [Car,parking]
StartEngine [Car,parking] DriveOff
[Car,parking]
UseKey[Car,parking]
ShortIgnition[Car,parking]
OpenDoor
Convenience [OpenDoor]
Break-in[Car,parking]
UseDoorRemoteControl [Car,parking]
-
-
-
-
-
-
X
X
X
!
Availability[Car,driving]
Availability[Car,parking]
Node-countering countermeasureUseKey counters StartEngine
Link-countering hazardBreak-in counters the countermeasuring of LockDoor on AccessCabin
Link-countering countermeasureUseDoorRemoteControl counters the side-effect of LockDoor on Convenience NFR
LockDoor[Car,parking]
Convenience [OpenDoor]
UseDoorRemoteControl [Car,parking]
--
--
AccessCabin [Car,parking]
Break-in[Car,parking]
? ?
Diagrammatically unclear which negative contribution is countered.
Node-countering hazardShortIgnition counters UseKey
Node-countering countermeasureLockTransmission counters ShortIgnition
LockTransmission[Car,parking]
Security [Car]
Theft [Car,parking]
ControlCar
Car
ParkCar
Driver
LockTransmission
«extend»
«trace»
Confidentiality[Car]
Availability[Car]
-
LockDoor[Car,parking]
-AccessCabin [Car,parking]
StartEngine [Car,parking] DriveOff
[Car,parking]
UseKey[Car,parking]
ShortIgnition[Car,parking]
OpenDoor
Convenience [OpenDoor]
Break-in[Car,parking]
UseDoorRemoteControl [Car,parking]
-
-
-
-
-
-
!
Availability[Car,driving]
Availability[Car,parking]
Determining NFR satisficing
X
X
X
accepted by the stakeholders
denied as it is negated by the countermeasure
satisficed as its hazard has been negated
denied as it is negated by the countermeasure
denied because an offspring of AND-decomposition is denied
satisficed as its hazard has been negated
accepted by the stakeholders
satisficed as its countermeasure has been negated
satisficed as the side-effect has been negated
LockTransmission[Car,parking]
Security [Car]
Theft [Car,parking]
ControlCar
Car
ParkCar
Driver
LockTransmission
«extend»
«trace»
Confidentiality[Car]
Availability[Car]
-
LockDoor[Car,parking]
-AccessCabin [Car,parking]
StartEngine [Car,parking] DriveOff
[Car,parking]
UseKey[Car,parking]
ShortIgnition[Car,parking]
OpenDoor
Convenience [OpenDoor]
Break-in[Car,parking]
UseDoorRemoteControl [Car,parking]
-
-
-
-
-
-
X
X
X
!
Availability[Car,driving]
Availability[Car,parking]
Implementing the countermeasures
Include ignition key as a part of the car architecture
Reflect LockTransmission behavior in the functional requirements
An experimental case study of car hazard analysis
LockTransmission[Car,parking]
Security [Car]
Theft [Car,parking]
Control
Car
ParkCar
Driver
AutoUnlockDoors
«extend»
«trace»
Security[Car,driving]
Security[Car,parking]
-
LockDoor[Car,parking]
-AccessCabin [Car,parking]
StartEngine [Car,parking]
Drive [Car,parking]
UseKey[Car,parking]
ShortIgnition[Car,parking]
OpenDoor
Convenience [door-control]
Break-in[Car,parking] Use
RemoteControl [Car,parking]
--
-
- -
-
X
X
DriveOff-theft [Car,parking]
Tow-theft [Car,parking]
LiftSensor [Car,parking]
WeightOnWheelSensor [Car,parking]
GPSTracking [Car,parking]
Cost [Car]
!
-+ +
- -
+
Convenience [Maintenance,Tow]
-
On/OffButton,LiftSensor[Car,parking]
-LockSteeringWheel [Car,parking]
-
SteeringWheelLockClub [Car,parking]
X
X
X
X
BreakGlass[Car,parking]
UnlockDoor[Car,parking]
UnlockFromDoorPanel[Car,parking]
GlassBreakSensor[Car,parking]
DimondCutter[Car,parking]
-
-PullLockButton[Car,parking]
LockPicking[Car,parking]
++
+++
UseTaperedLockButton[Car,parking]
-
UseFakeKey[Car,parking]
IgnitionEnabledByChipInKey[Car,parking]
-
-
-
Cost [Car]
-
--
--
UseDifficultToPickLock[Car,parking]
CodeGrabbing[Car,parking]
RollingCodeRemote[Car,parking]
Forget[Car,parking]
AutoLockDoor[Car,parking]
Convenience [window-control]
Convenience [car-control]
PoweredWindow[window-control]
+
Safety [Driver]
LockDoor
Safety[Driver, Acc, OnLand]
X
X
!
Safety [Driver, Acc, Submerged]
Safety[Driver,DuringAccident]
Claim[“Battery malfunction underwater”]
+
-AutoUnlockWhenNoPower[window-control]
DriveCar
X
X
X
X
X
X
X
X
Safety[Driver,driving]
Convenience [Maintenance,Tow] «trace»
«trace»X
Robbery[Driver,driving]
-
LockDoor[Car,driving]
Claim[“Not operable if connection to battery damaged”]
- +
-
extension point = power loss while driving
-
X
-
X
«extend»
AutoLockDoors
«trace»
Availability[Car,parking]
Confidentiality[Car,parking]
X
X
Claim[“Low probability because dimond cutter is too expensive for most car thieves”]
Hypotheses:1. The goal-oriented approach
is suitable for hazard analysis?
2. Non-attacker-driven hazard elicitation is not intuitive for hazard analysis
3. The goal-oriented approach is well integrated with the use case modeling
Suitability of the goal-oriented approach for hazard analysis
Explicit representation of hazards and corresponding countermeasures→ hazard = operationalization with negative contribution toward NFR→ countermeasure = operationalization with negative contribution toward
hazard Focused hazards elicitation
→ NFR-driven elicitation→ focus more on hazards of critical NFRs
Reasoning framework→ explore multiple countermeasures→ select based on degree of contribution and supporting claims
Integration with requirements model→ associate NFRs with use case model elements→ map countermeasures to additional use cases
Intuitiveness of the non-attacker-driven approach
Comparing with attacker-driven approaches
Not as intuitive for hazards initiated by real agentsThief → initiates “CarTheft” hazardRobber → initiates “Robbery” hazard
More natural for unintentional hazards “EngineBreakDown” hazard:
unnatural to model “wear and tear” as the attacker
“CarSkid” hazard:unnatural to model “bad weather” as the attacker
Good integration with use case model
Pros: forward integration by associating NFRs (the starting
point of hazard elicitation) with use case model elements
backward integration by mapping countermeasures to additionaluse cases
Cons: the hazard analysis not integrated and performed in
the use case model
Benefits and limitation of the approach
Benefits: complement &
transparency to positive modeling
natural for risk related NFRsoperationalizations are
countermeasures of some hazards
difficult to identify operationalization that is not a countermeasure of some hazard
Theft [Car,parking]
-
-AccessCabin [Car,parking]
StartEngine [Car,parking] DriveOff
[Car,parking]
Responsive [SoftwareSystem]
-
Availability[Car,parking]
LockDoor[Car,parking]
UseKey[Car,parking]
QuickFrequentStatusUpdate
+
Security[Car,parking]
eql
?+
XX
X
some countermeasures may partially/slightly negate the hazard
some other may more strongly negate the hazard
Limitation: no explicit
representation of natural attackers
need different degrees of negative contribution
ConclusionContributions: • use of negative contribution to represent hazards
and countermeasures• introduction of link-associated operationalization to
provide precise context for countermeasures• the car hazard analysis to illustrate the application of
the goal-oriented approach
Future work: • use different degrees of negative contribution for
hazards and countermeasures• refine label propagation to deal with different
degrees of negative contributions
Applying a Goal-Oriented Method for Hazard Analysis:
A Case Study
Sam SupakkulThe University of Texas at Dallas
Lawrence ChungThe University of Texas at
Thank you!