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

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

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

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

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

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

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

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

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

10. More/Backup
More cases for offline viewing
References

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

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

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

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

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

16. 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 , 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 , 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, Nov 2001.
[Alexander2003] Ian Alexander: Misuse Case Help To Elicit Nonfunctional Requirements, IEE CCEJ, 2001