1 / 16

Security (Mis)use Cases: A Rationale for Threat Identification and Requirements Generation

This document explores the use of security (mis)use cases to capture threats and generate requirements from the perspective of an attacker. It provides examples of (mis)use cases and explains the importance of considering security from different viewpoints. The document also outlines a proposed process for capturing and prioritizing threats, as well as forming a sub-team for generating security threats and requirements. Additional backup cases and references are provided.

mberryhill
Download Presentation

Security (Mis)use Cases: A Rationale for Threat Identification and Requirements Generation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Threat Forge Routing Packets Use and (Mis)use cases System Function User • Use cases view system from user’s viewpoint • Misuse cases view system from misuser/attacker’s viewpoint Routing Detect and Reject Forged packets Mesh Use Case: Send data across mesh Mitigates MisUser

  4. Why Security (Mis)use Cases? • 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. Threat New System Functions/Requirements (Mis)use case: Forge routing packet System Function User Routing Forge Routing Packets Detect and Reject Forged packets Mesh Use Case: Send data across mesh Mitigates MisUser

  6. Threat and requirements generated • Threat • 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)

  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

  14. Example (Mis)use case: Case1 Path3

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

More Related