1. Applying a Goal-Oriented Method for Hazard Analysis: A Case Study Sam Supakkul The University of Texas at Dallas ssupakkul@ieee.org Lawrence Chung The University of Texas at Dallas chung@utdallas.edu

2. e-commerce system related “hazards” steal card info flood system Adapted from: G. Sindre and A. Opdahl, “Eliciting Security Requirements by Misuse Cases”, TOOLS Pacific 2000 E. 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 repudiation spoofing hazard = an obstacle to product’s goal achievement

3. 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

4. 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 attackers e.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

5. 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

6. 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 model Integrate with the UML use case model

7. 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

8. Representing NFRs as softgoals in the use case model [Supakkul and Chung, SERA 04] The association provides context for the NFRs Security of the system (car) Convenience of the interface ! ! → important NFR !! → critical NFR

9. Refine NFRs and explore solution alternatives [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 softgoals 2. Explore solution alternatives (operationalization) 4. Make trade-offs analysis and finalize design decisions 3. Record arguments “for” or “against” choices and contributions Naming convention = Type [Topic] Type = Availability, Topic = EMS Negative contribution for side-effects !

10. Hazard analysis process perform hazard analysis before the regular NFR operationalization analysis Reason: some operationalizations are natural countermeasures of some hazards. e.g. LockDoor to counter Theft

11. Hazard analysis for car hazard = 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.

12. Traceability between hazards and countermeasures Node-countering countermeasure UseKey counters StartEngine Link-countering hazard Break-in counters the countermeasuring of LockDoor on AccessCabin Link-countering countermeasure UseDoorRemoteControl counters the side-effect of LockDoor on Convenience NFR Diagrammatically unclear which negative contribution is countered. Node-countering hazard ShortIgnition counters UseKey Node-countering countermeasure LockTransmission counters ShortIgnition

13. Determining NFR satisficing 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

14. Implementing the countermeasures Include ignition key as a part of the car architecture Reflect LockTransmission behavior in the functional requirements

15. An experimental case study of car hazard analysis 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

16. 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

17. Intuitiveness of the non-attacker- driven approach Comparing with attacker-driven approaches Not as intuitive for hazards initiated by real agents Thief → initiates “CarTheft” hazard Robber → 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

18. 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

19. Benefits and limitation of the approach Benefits: complement & transparency to positive modeling natural for risk related NFRs operationalizations are countermeasures of some hazards difficult to identify operationalization that is not a countermeasure of some hazard 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

20. Conclusion Contributions: 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

21. Applying a Goal-Oriented Method for Hazard Analysis: A Case Study Sam Supakkul The University of Texas at Dallas ssupakkul@ieee.org Lawrence Chung The University of Texas at Dallas chung@utdallas.edu Thank you!