Discussing “Developing Secure Systems with UMLSec”

1. Discussing “Developing Secure Systems with UMLSec” 15 FEB 2006 - Joe Combs

2. What Problem are we Trying to Solve? Blindly inserting security mechanisms into a system doesn’t work Need to bring efforts to mitigate these design limitations before system is actually implemented

3. Introducing UMLSec • Extension of Unified Modeling Language - de-facto standard for OO development • Attempt to encapsulate & make available to developers knowledge on prudent security engineering • Encapsulation and modularity makes OO systems very well suited to considering security

4. UML Diagrams of Interest • Use Case - typical interaction between user and system • Activity - workflow modeling/detailed explanation of use case • Class - static structure of the system • Interaction - sequence or collaboration diagram describes interaction between objects via message exchange • State Chart - dynamic component behavior within an object • Package - groups parts of a system into higher level units • Deployment - describes physical arrangement in a real-world instance

5. UMLSec Notation • Stereotypes • <<stereotype>> • Extensibility mechanism used to create meta-information about an entity in the diagram • Tag-Value Pairs • {tag,value} • Extensibility mechanism to describe a property of a model element

6. Use Case Diagram <<fair exchange>>: if “buys goods” then eventually “sells goods”

7. Activity Diagram Solution on right gives fair exchange if payment is <<provable>>

8. Class Diagram • Ensure class structure provides data security • Key::newkey() guarantees confidentiality & integrity • but random does not!

9. Interaction Diagram • Purchase system sends Init message to access card passing a session key signed with M’s private key and encrypted with C’s public key • C decrypts the session key with its private key and verifies signature with M’s public key • Once session key has been verified in this way, C can encrypt and send secrets using the session key and pass to M on the Resp message

10. State Chart Diagram • Ensure behavior within a component - access control, database security, etc. • Transition labels: • events - message called on this object • [conditions] - must be true for transition to fire • \actions - carried out if transition fires

11. Package Diagram Uses visibility of parts within packages to reason about access privileges

12. Deployment Diagram • Express security requirements on physical layer of the system: • communication links • hardware security • etc.

13. Security Patterns Operation rx() leaks information on the account balance

14. The Wrapper Pattern Ensures no low read after a high write

15. Now What? • UMLSec provides a mechanism for communicating security concerns, bringing security up to the requirements and design phases of the lifecycle • Where can this go from here? • Incorporate UMLSec notation for association, generalization, etc. • Formal methods approaches?