Applying a Goal-Oriented Method for Hazard Analysis: A Case Study

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 server down unauthorized account disclosure obtain password spoofing repudiation hazard = an obstacle to product’s goal achievement 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

3. Car related “hazards” paint fading robbery 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? broken antenna engine break-down rusting theft driver injury

4. Current practice – misuse cases Misuse case threatens use case • 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 Countermeasure use case mitigates misuse case Real attackers e.g. crook, thief Imaginary attackers e.g. bad luck, bad weather [G. Sindre and A. L. Opdahl, “Eliciting Security Requirements with Misuse Cases”, Requirements Engineering 2002]

5. Current practice – fault tree • Hazard relationships through AND/OR decomposition • Only hazards are represented • Independent of requirements model Fault or hazard Refine hazard with AND/OR decomposition Detailed hazard [D. Lu and R. Lutz, “Fault contribution trees for product families”, ISSRE 2002]

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 ! → important NFR !! → critical NFR Security of the system (car) ! Convenience of the interface The association provides context for the NFRs [Supakkul and Chung, SERA 04]

9. Refine NFRs and explore solution alternatives 1. Refine NFR softgoals 2. Explore solution alternatives (operationalization) 3. Record arguments “for” or “against” choices and contributions 4. Make trade-offs analysis and finalize design decisions NFR Softgoal Naming convention = Type [Topic] Type = Availability, Topic = EMS AND Decomposition ! Negative contribution for side-effects Positive Contribution for possible solutions NFR Operationalization Claim [J. Mylopoulos and L. Chung 92, L. Chung et. al 2000]

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 Diagrammatically unclear which negative contribution is countered. Node-countering countermeasure UseKey counters StartEngine Link-countering countermeasure UseDoorRemoteControl counters the side-effect of LockDoor on Convenience NFR Node-countering hazard ShortIgnition counters UseKey Link-countering hazard Break-in counters the countermeasuring of LockDoor on AccessCabin Node-countering countermeasure LockTransmission counters ShortIgnition

13. Determining NFR satisficing satisficed as the side-effect has been negated satisficed as its countermeasure has been negated satisficed as its hazard has been negated denied because an offspring of AND-decomposition is denied denied as it is negated by the countermeasure satisficed as its hazard has been negated denied as it is negated by the countermeasure accepted by the stakeholders accepted by the stakeholders

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: • The goal-oriented approach is suitable for hazard analysis? • Non-attacker-driven hazard elicitation is not intuitive for hazard analysis • 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 countermeasurestoadditional 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 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 difficult to identify operationalization that is not a countermeasure of some hazard

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!