UP and Security: Penetrate-and-patch Overview of UMLsec (aka - PDF document

2 Software Engineering & Security UP and Security: „Penetrate-and-patch“ Overview of UMLsec (aka „banana strategy): Jan Jürjens • insecure Competence Center for IT Security • disruptive Software & Systems Engineering Traditional formal methods: expensive. TU München • training people • constructing formal specifications. http://www.umlsec.org Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 2 Security by Design Model-based Security with Aspects Increase security with bounded • Weave in security Aspects investment in time, costs: aspects into UMLsec models. Weave in • Weave in security aspects/concerns into artefacts arising in industrial development • Generate code (or Models tests) from models. and use of security-critical systems (UML Codegen. Modelgen./ models, source code, configuration data). • Generate models Testgen. Reverse E. from evolving or Code • Tool-supported, theoretically sound, Code legacy code. efficient automated security synthesis. Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 3 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 4 UMLsec: How UMLsec: Goals Extension for secure systems development. Recurring security requirements, adversary • evaluate UML specifications for weaknesses scenarios, concepts offered as stereotypes in design with tags on component-level. • encapsulate established rules of prudent Use associated constraints to verify secure engineering as checklist specifications using automated theorem • make available to developers not specialized provers and indicate possible weaknesses. in secure systems Ensures that UML specification provides • consider security requirements from early desired level of security requirements. design phases, in system context Link to code via round-trip engineering etc. • make certification cost-effective Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 5 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 6 1

2 Application Level The Security Process Requirements with Use Case Diagrams Business Process Security Enhancements Modelling «fair exchange» Sales application Application Risk Requirements Analysis buys goods Elicitation sells goods Application Customer Business iterative Architecture Modelling Development Capture security requirements in use case diagrams. Constraint: need to appear in Software Architecture Technical Risk Modelling Analysis corresponding activity diagram. Security Enhancements Technical Level Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 7 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 8 Purchase «fair exchange» ≪ fair exchange ≫ Fair Exchange {start={Pay}} {stop={Reclaim,Pick up}} Customer Business Customer buys good Ensures generic fair exchange condition. Request good from a business. How can enforce fair Constraint: after a {start} state in activity Pay exchange: diagram is reached, eventually reach After payment, Wait until {stop} state. customer is delivery due Deliver eventually either undelivered delivered (Cannot be ensured for systems that an delivered good or Pick up able to reclaim attacker can stop completely.) Reclaim payment (or vc.vs.). Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 9 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 10 Purchase «fair exchange» Example ≪ Internet ≫ , ≪ encrypted ≫ , … {start={Pay}} {stop={Reclaim,Pick up}} Customer Business ≪ fair exchange ≫ Kinds of communication links resp. system Request good fulfilled if adversary nodes. cannot stop Pay For adversary type A, stereotype s, have set system: After Threats (s) ∊ {delete, read, insert, access} A payment, customer Wait until of actions that adversaries are capable of. delivery due Deliver is eventually either Default attacker: undelivered delivered Stereotype Threats () default delivered good or Internet {delete, read, insert} Pick up able to reclaim encrypted {delete} Reclaim LAN payment. ∅ smart card ∅ Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 11 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 12 2

2 ≪ secure links ≫ Secure Architecture «secure links» Remote access Ensures that physical layer meets security requirements on communication. Constraint: for each dependency d with stereotype client machine «secrecy» server machine s ∊ { ≪ secrecy ≫ , ≪ integrity ≫ } between get_password components on nodes n ≠ m, have a «call» web server client apps access control browser communication link l between «Internet» n and m with stereotype t such that • if s = ≪ secrecy ≫ : have read ∉ Threats (t). A Architecture secure against default • if s = ≪ integrity ≫ : have insert ∉ Threats (t). A adversary ? Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 13 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 14 Example ≪ secure links ≫ Secure Data Structure «secure links» Remote access «secure dependency» Key generation client machine «secrecy» server machine newkey(): Key «interface» get_password Random number «call» web server client apps Key generator «critical» access control browser «Internet» Random generator random(): Real {secrecy={newkey(),random()} seed: Real Given default adversary type, constraint newkey(): Key random(): Real «call» for stereotype ≪ secure links ≫ violated: According to the Threats default (Internet) scenario, ≪ Internet ≫ link does not provide Data structure secure ? secrecy against default adversary. Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 15 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 16 ≪ secure dependency ≫ Example ≪ secure dependency ≫ «secure dependency» Ensure that ≪ call ≫ and ≪ send ≫ Key generation dependencies between components respect newkey(): Key «interface» Random number security requirements on communicated data Key generator «critical» Random generator given by tags {secrecy}, {integrity}. random(): Real {secrecy={newkey(),random()} seed: Real Constraint: for ≪ call ≫ or ≪ send ≫ dependency newkey(): Key random(): Real «call» from C to D (and similarly for {integrity}): • Msg in D is {secrecy} in C if and only if also in D . Violates ≪ secure dependency ≫ : Random • If msg in D is {secrecy} in C, dependency generator and ≪ call ≫ dependency do not give stereotyped ≪ secrecy ≫ . security level for random() to key generator. Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 17 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 18 3

2 Secure Use of Cryptography ≪ data security ≫ Security requirements of data marked ≪ critical ≫ enforced against threat scenario from deployment diagram. Variant of TLS Constraints: Data marked {secrecy}, (INFOCOM`99). Cryptoprotocol {integrity}, {authenticity}, {fresh} fulfills secure against respective formalized security default requirements. adversary ? Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 19 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 20 Example ≪ data security ≫ What Does UMLsec Cover ? Security requirements : ≪ secrecy ≫ ,… Threat scenarios: Use Threats adv (ster). Security concepts: For example ≪ smart card ≫ . Security mechanisms: E.g. ≪ guarded access ≫ . Variant of TLS Security primitives: Encryption built in. (INFOCOM`99). Physical security: Given in deployment diagrams. Violates {secrecy} of s Security management: Use activity diagrams. against default Technology specific: Java, CORBA security. adversary. Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 21 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 22 Model-based Security Aspects Secure Channel Aspect Primary model with • Define abstract security aspect. directives • Define concretization (e.g. protocol). for security • If possible, give conditions under which aspects (cf. it is secure to weave in aspect using join points concretization, e.g. by simulation argument. in AspectJ). To keep d secret, must be sent encrypted. Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 23 Jan Jürjens, TU Munich: UP and Security: Overview of UMLsec 24 4