CSCE 548 Secure Software Development Use Cases Misuse Cases

Reading Required: McGraw: Chapter 8 I. Alexander, Misuse Cases: Use Cases with Hostile Intent, IEEE Software, vol. 20, no. 1, pp. 58-66, Jan./Feb. 2003. http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2003.1159030 Recommended” Pauli and Xu, Misuse Case-Based Design and Analysis of Secure Software Architecture, http://cs.ndsu.edu/~dxu/publications/pauli-xu-ITCC05.pdf Steven and Peterson, Defining Misuse within the Development Process, http://csdl.computer.org/dl/mags/sp/2006/06/j6081.pdf Next lecture: Security Operations CSCE 548 - Farkas

Application of Touchpoints External Review 3. Penetration Testing 1. Code Review (Tools) 6. Security Requirements 4. Risk-Based Security Tests 2. Risk Analysis 7. Security Operations 5. Abuse cases 2. Risk Analysis Requirement and Use cases Architecture and Design Test Plans Code Tests and Test Results Feedback from the Field CSCE 548 - Farkas

Design Flaws 50 % of security problems Need: explicitly identifying risk Quantifying impact: tie technology issues and concerns to business Continuous risk management CSCE 548 - Farkas

Unified Modeling Language Standard way to visualize a system's architectural blueprints High abstraction level Extensible syntax Sufficiently precise semantics Can we express security requirements in UML? CSCE 548 - Farkas

UML Diagrams Source: Wikipedia, http://en.wikipedia.org/wiki/Unified_Modeling_Language CSCE 548 - Farkas

UMLsec Uses extension mechanism of UML and its formal semantics Relies on work providing formal semantics for UML Security considerations: need formal semantics to reason about security requirements CSCE 548 - Farkas

AuthUML Alghathbar and Wijesekera Formal semantics for UML diagrams Horn clauses Additional logic constructs to model Authorization constraints CSCE 548 - Farkas

authUML This unified framework supports Derivation of authorization Verification of consistency of the integrated security policies Resolution of conflicting requirement Application of default policy CSCE 548 - Farkas

Use Case Example CSCE 548 - Farkas Copyright: Alghathbar and Wijesekera

Misuse Cases Software development: making software do something Describe features and functions Everything goes right Need: security, performance, reliability Service level agreement – legal binding How to model non-normative behavior in use cases? Think like a bad guy CSCE 548 - Farkas

Software Vendor Accountability SLA for specific, measurable criteria: Proper implementation of security features Looking for known security flaws and confirming that they are not present Passing third party validation and verification Use of source code analysis tools CSCE 548 - Farkas

Checking for Known Vulnerabilities Need tool Possible attacks and attack types How the software behaves if something goes WRONG What motivates an attacker? CSCE 548 - Farkas

Misuse Cases Extends use case diagrams Represent actions the system should prevent Represent together Desired functionalities Undesired actions Security: emergent property  must be built in from the ground up Making explicit trade offs CSCE 548 - Farkas

Misuse Cases Analyze system design and requirements Assumptions Failure of assumptions Attack patterns Software that is used also going to be attacked What can a bad guy do and how to react to malicious use CSCE 548 - Farkas

Misuse Case Development Team work – software developers and security experts Identifying and documenting threats Creating anti-requirements: how the system can be abused Creating attack model Select attack pattern relevant to the system Include anyone who can gain access to the system CSCE 548 - Farkas

Link to presentation on Ian Alexander’s paper on Misuse Cases: Use Cases with Hostile Intent, perceval.gannon.edu/xu001/teaching/shared/re_eng/slides/misusecase.ppt CSCE 548 - Farkas

Next Class Operational security CSCE 548 - Farkas