A rationale for security (mis)use cases May 11, 2004 Jasmeet Chhabra Key contributors: Jesse Walker W Steven Conner

Outline Use and (Mis)use cases Why Security (mis)use cases? Example case for the mesh Single illustrative case A possible way to capture the example case Conclusion and Next steps Backup has a few more use cases for offline perusal

Detect and Reject Forged packets Use and (Mis)use cases System Function Threat Forge Routing Packets User Routing Detect and Reject Forged packets Use Case: Send data across mesh Mesh Mitigates Use cases view system from user’s viewpoint Misuse cases view system from misuser/attacker’s viewpoint MisUser

Why Security (Mis)use Cases? view scenarios from point of view of the user We need to view software from the point of view of the attacker / misuser / malicious user Use to capture / generate a threat model Know what it means to be “secure” Build security into the design

(Mis)use case: Forge routing packet System Function Threat User Routing Forge Routing Packets Detect and Reject Forged packets Use Case: Send data across mesh Mesh New System Functions/Requirements Mitigates MisUser

Threat and requirements generated The misuser generates and sends a forged routing packet to cause misrouting Requirements The mesh shall identify the forged routing packet as invalid The mesh does not use the forged routing packet to generate/update routes The mesh shall have prevented the misuser from misrouting using forged packets

Illustrative (Mis)use case: Case1 Path1 (A possible way to capture) System function / Use Case: Routing Use Case Path: Forge Routing packet Security Threat: The misuser generates and sends a forged routing packet to cause misrouting Preconditions: 1) The misuser can generate and send a forged routing packet with wrong information Misuser / attacker interactions System Requirements System Interactions System Actions  The misuser generates and senda a forged routing packet with wrong information The mesh shall identify the forged routing packet as invalid The mesh does not use the forged routing packets to generate/update routes Postconditions: 1) The mesh shall have prevented the misuser from misrouting using forged packets

Proposed process for Security functional component Security (Mis)use cases Threats and requirements Prioritize threats Shall handle / Will not handle Evaluation Criteria

Conclusion and Next steps Security (mis)use cases look at system from attacker’s point of view Use cases look from user’s point of view Document security (mis)use cases Capture/Prioritize threats and requirements Propose: Form a sub-team to Generate security threats/requirements Feed into evaluation criteria Know what it means to be “secure”

More/Backup More cases for offline viewing References

Terminology Used Terminology: Misuser: Attacker or malicious user Discovery Packets: Packets used to discover neighbors in order to create a mesh connectivity topology

A proposal to capture security (Mis)use cases Now: No architectural assumptions Capture any assumptions/threats Driven by misuser/ attacker Generate threat model and requirements for evaluation criteria Later: after some architecture is in place More detailed threat model Generate test criteria for implementation/ design

Example (Mis)use case: Case1 Path2 Use Case: Routing Use Case Path: Replay Security Threat: The misuser replays routing packets to cause packets to misroute Preconditions: 1) The misuser can overhear routing packets and replay them Misuser interactions System Requirements System Interactions System Actions  The misuser attempts to misroute packets by replaying routing packets The mesh shall identify the replayed routing packets as duplicates The mesh does not use the replayed routing packets to generate/update routes Postconditions: 1) The mesh shall have prevented the misuser from misrouting using replayed packets 2) The mesh shall have logged the attempt to replay routing packets

Example (Mis)use case: Case1 Path3 Use Case: Routing Use Case Path: Selective forwarding Security Threat: The misuser uses selected forwarding of packets to break system routing functions Preconditions: 1) The misuser has an AP/routing node authenticated in the mesh network Misuser interactions System Requirements System Interactions System Actions The misuser attempts to selectively forward packets and break routing functions The mesh shall identify the selective forwarding behavior of the misuser The mesh shall un-authenticate the node using selective forwarding to break mesh routing functions and deny future access Postconditions: 1) The mesh shall have prevented the misuser from using selective forwarding to break mesh routing functions 2) The mesh shall log the attempt to circumvent the routing functions.

Other possible categories Discovery Routing – many more Access Policy Data Security Denial of Service (Mis)use cases generated from use cases More…

References Misuse and Abuse Cases: Getting Past the Positive, Paco Hope, Annie I. Antón and Gary McGraw. IEEE Security & Privacy, February 2004. Donald G. Firesmith, “Engineering Security Requirements,” Journal of Object Technology (JOT), 2(1), Swiss Federal Institute of Technology (ETH), Zurich, Switzerland, p. 53-68, January/February 2003. Donald G. Firesmith, “Security Use Cases,” Journal of Object Technology (JOT), 2(3), Swiss Federal Institute of Technology (ETH), Zurich, Switzerland, p. 53-64, May/June 2003. [Sindre and Opdahl 2001] Guttorm Sindre and Andreas Opdahl: Templates for Misuse Case Description, 2001, R. Crook, D. Ince, L. Lin, and B. Nuseibeh, "Security Requirements Engineering: When Anti-Requirements Hit the Fan", Proceedings of IEEE International Requirements Engineering Conference (RE'02), Essen, Germany, September 2002. Guttorm Sindre, Andreas L. Opdahl: "Capturing Security Requirements by Misuse Cases", In Proc. 14th Norwegian Informatics Conference (NIK'2001), Tromsø, Norway, 26-28 Nov 2001. [Alexander2003] Ian Alexander: Misuse Case Help To Elicit Nonfunctional Requirements, IEE CCEJ, 2001