1. CSCE 548 Secure Software Development Use Cases Misuse Cases

2. Reading Required: McGraw: Chapter 8
I. Alexander, Misuse Cases: Use Cases with Hostile Intent, IEEE Software, vol. 20, no. 1, pp , Jan./Feb
Recommended”
Pauli and Xu, Misuse Case-Based Design and Analysis of Secure Software Architecture,
Steven and Peterson, Defining Misuse within the Development Process,
Next lecture:
Security Operations
CSCE Farkas

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

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

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

6. UML Diagrams Source: Wikipedia,
CSCE Farkas

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

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

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

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

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

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

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

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

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

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

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

18. Next Class
Operational security
CSCE Farkas