1. CSCE 548 Secure Software Development Security Use Cases

2. CSCE 548 - Farkas2 Reading This lecture: – Jan Jürjens, Towards Development of Secure Systems using UMLsec, http://citeseer.ist.psu.edu/536233.htmlhttp://citeseer.ist.psu.edu/536233.html – Lodderstedt et. al, SecureUML: A UML-Based Modeling Language for Model-Driven Security, http://citeseer.ist.psu.edu/lodderstedt02secureuml.html http://citeseer.ist.psu.edu/lodderstedt02secureuml.html – K. Alghathbar and D. Wijesekera, authUML: a three- phased framework to analyze access control specifications in use cases, http://portal.acm.org/citation.cfm?id=1035438 http://portal.acm.org/citation.cfm?id=1035438 Next lecture: – Misuse Cases, McGraw: Chapter

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

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

5. CSCE 548 - Farkas5 SecureUML Lodderstedt, Basin, and Doser Role-Based Access Control, MAC Use UML to specify access control – Security is “horizontal” to software development – Ad-hoc and “after-the-development” security integration is error prone, can be costly, and may have negative impact

6. CSCE 548 - Farkas6 SecureUML Model-driven software development integrated with security Advantages: – Security is integrated during software design, using high-level of abstraction – Modeling information can be used to detect design errors and verify correctness Limitations: need precise semantics of modeling language for security assurance

7. CSCE 548 - Farkas7 Unified Modeling Language Standard way to visualize a system's architectural blueprints High abstraction level Extensible syntax Sufficiently precise semantics

8. UML Elements Actors Business processes Logical components Activities Programming language statements Database schemas Reusable software components CSCE 548 - Farkas8

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

10. UML Specification Language Object Constraint Language (OCL) – Invariant for classes – Preconditions and post conditions for methods – Guards for transitions in state machines First –order logic – E.g., context Meeting inv: self.participants -> includes(self.owner) Stereotypes: sub-typing Tagged values: (tag, value) CSCE 548 - Farkas10

11. CSCE 548 - Farkas11 RBAC Intuitive and easy to administer Well established and supported by a large number of software platform Limitation: expressing access conditions based on system state  Authorization Constraints (Object Constraint Language)

12. CSCE 548 - Farkas12 RBAC 3.... U Users R Roles P Permissions. S Sessions User assignment Permission assignment Constraints

13. CSCE 548 - Farkas13 Mandatory Access Control Objects: security classification e.g., grades=(confidential, {student-info}) Subjects: security clearances e.g., Joe=(confidential, {student-info}) Access rules: defined by comparing the security classification of the requested objects with the security clearance of the subject e.g., subject can read object only if label(subject) dominates label(object)

14. CSCE 548 - Farkas14CSCE 522 - Farkas14 Lecture 17 Mandatory Access Control Security Labels: (A,C), where A: total order, e.g., Top-Secret > Secret > Public C: domain (subset), e.g., subsets of the set {5, 7} are: {5,7}, {5}, {7}, {} and {5,7}  {5,7}|{5}|{7}|{}, {5}  {5}|{}, {7}  {7}|{}, {}  {} but {7} NOT  {5} Dominance (  ): label l=(A,C) dominates l’=(A’,C’) iff A  A’ and C  C’ e.g., (confidential,{student-info})  (public,{student-info}) BUT (confidential, {student-info}) NOT  (public,{student-info, department-info})

15. CSCE 548 - Farkas15CSCE 522 - Farkas15 Lecture 17 Bell-LaPadula Axioms Simple-security property: a subject s is allowed to read an object o only if the security label of s dominates the security label of o No read up Applies to all subjects *-property: a subject s is allowed to write an object o only if the security label of o dominates the security label of s No write down Applies to un-trusted subjects only

16. Model Driven Security Model building: standard practice in software engineering (e.g., MDA) Security policy specification (e.g., RBAC) Difficulties: – Security models and system design models are disjoint and expressed in different ways – Security considerations are missing in the middle of development (addressed in early development and final phases) CSCE 548 - Farkas16

17. Model Driven Architecture Model Driven Security CSCE 548 - Farkas17

18. Model Driven Architecture CSCE 548 - Farkas18 Source: D. Basin et a., ACM Trans. On Software Engineering and Methodology, 15(1), 2005

19. Model Driven Security CSCE 548 - Farkas19 Source: D. Basin et a., ACM Trans. On Software Engineering and Methodology, 15(1), 2005

20. Model Driven Security Security modeling language System design modeling language Dialect: connection point for integrating security and system models CSCE 548 - Farkas20 Source: D. Basin et a., ACM Trans. On Software Engineering and Methodology, 15(1), 2005

21. CSCE 548 - Farkas21 SecureUML Defines vocabulary for annotating UML-based models with access control information Abstract syntax: formal definition, e.g., grammar Concrete syntax: notation (UML profile) Host language: a modeling language that uses SecureUML SecureUML dialect: SecureUML specifications are refined in the host language – E.g., syntactic elements of the modeling language are transformed into constructs of the target platform Need capability to combine sub-expressions from different languages!

22. CSCE 548 - Farkas22 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

23. CSCE 548 - Farkas23 UML Diagrams and Security Class diagrams: static structure of the system – Class: attributes and operations/signals – Relationships between classes Statechart diagrams: dynamic behavior of individual objects – Events: change in the state or actions – Prevent indirect information flow Interaction diagram: interactions between objects via messages – Sequence diagrams – Correctness of security critical interactions

24. CSCE 548 - Farkas24 UMLsec Security labeling: UML extension construct tag Need formal semantics of UML diagrams – UMLSec uses a simplified semantics to convey security information

25. Secure UML Metamodel CSCE 548 - Farkas25 Source: D. Basin et al., ACM Trans. On Software Engineering and Methodology, 15(1), 2005

26. Concrete Syntax UML profile: formalizes the modeling notations of SecureUML – Stereotypes – Tagged values CSCE 548 - Farkas26

27. Other Approaches CSCE 548 - Farkas27

28. Top Ten Information Security Considerations in Use Case Modeling Gunnar Peterson, CTO, Arctec Group, http://www.arctecgroup.net/secusecase.htm http://www.arctecgroup.net/secusecase.htm 1. Synthesis: architectural tradeoff analysis 2. Stakeholders: capture and documentation of who is impacted by security 3. Pre- and postconditions: must be satisfied for the use case to execute and the system must end in a specified state 4. Exceptional and alternate flows: plan for failure 5. Actors: authorization structure, delegation CSCE 548 - Farkas28

29. Top Ten Information Security Considerations (cont.) 6. Modeling Identity: building, validating, and exchanging identities 7. Relationships: simplicity (includes, extends) 8. Mapping use cases to threat models 9. Architectural decision support: design-level tradeoff analysis 10. Test case development: security assurance measures CSCE 548 - Farkas29

30. CSCE 548 - Farkas30

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

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

33. CSCE 548 - Farkas33 Access Control (s, o,  a) Policy neutral AuthUML consists of three phases Policies written as finite collections of Horn clauses – alertReq(Xs,Xuc)  candoUC(Xs,+Xuc), candoUC(Xs,  Xuc)

34. CSCE 548 - Farkas34 Use Case Example Copyright: Alghathbar and Wijesekera

35. CSCE 548 - Farkas35 Examples PredicateDescription UC_OP(X uc,X op )Operation X op is part of Use Case X uc OP_OBJ(X op,X obj )Operation X op belongs to object X obj. before(X op,X’ op )Operation X op must be invoked before X’ op. inUCbefore(X uc,X op, X’ op ) Use Case X uc invokes X op before X’ op.

36. CSCE 548 - Farkas36 Examples PredicateDescription conflictingSubject(X s,X’ s )Subjects X s and X’ s conflict with each other. conflictingUC(X uc, X’ uc )Use case X op and X’ op conflict with each other. conflictingOP(X op, X’ op )Operations X op and X’ op conflict with each other. ignore(X,Y,Y’)Ignore a conflict among X,Y and Y’ where X, Y and Y’ are either subjects, operations or Use Cases

37. CSCE 548 - Farkas37 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

38. CSCE 548 - Farkas38 Software Vendor Accountability Proper implementation of security features Looking for known security flaws Passing third party validation Source code analysis

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

40. CSCE 548 - Farkas40 Next Class Misuse Cases