Software & Systems Engineering Informatics, TU Munich, Germany juerjens@in.tum.de - PowerPoint PPT Presentation

critical system development using mbra and umlsec methods and tools jan j rjens and siv hilde houmb n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software & Systems Engineering Informatics, TU Munich, Germany juerjens@in.tum.de PowerPoint Presentation
Download Presentation
Software & Systems Engineering Informatics, TU Munich, Germany juerjens@in.tum.de

play fullscreen
1 / 117
Software & Systems Engineering Informatics, TU Munich, Germany juerjens@in.tum.de
320 Views
Download Presentation
iram
Download Presentation

Software & Systems Engineering Informatics, TU Munich, Germany juerjens@in.tum.de

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Critical System Development using MBRA and UMLsec: Methods and ToolsJan Jürjens and Siv Hilde Houmb Software & Systems Engineering Informatics, TU Munich, Germany juerjens@in.tum.de http://www.jurjens.de/jan and Department of Computer and Information Science, NTNU, Norway sivhoumb@idi.ntnu.no

  2. Critical Systems Development • High quality development of critical systems (dependable, security-critical, real-time,...) is difficult. • Many systems developed and deployed do not satisfy their criticality requirements, sometimes with spectacular failures. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  3. Quality vs. Cost • Systems on which human life and commercial assets depend need careful development. • Systems operating under possiblesystem failure or attack need to befree from weaknesses. • Correctness in conflict with cost. • Thorough methods of system design not used if too expensive or not efficient enough (time is money and one needs to deliver). Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  4. Requirements Models Designs Systems Model-based Development/Design Synthesis Goal: ease transition from human ideas to executable systems. The layer bellow is a realisation of the layer above. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  5. Using UML UML: unprecedented opportunity for high-quality critical systems development feasible in industrial context: • De-facto standard in industrial modeling: large number of developers trained in UML. • Relatively precisely defined (given the user community). • Many tools in development (also for analysis, testing, simulation and transformation). Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  6. Challenges • Adapt UML to critical system application domains. • Correct use of UML in the application domains. • Conflict between flexibility and unambiguity in the meaning of a notation (ontology). • Improving tool-support for critical systems development with UML. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  7. Content of This Tutorial Background knowledge on using UMLsec and MBRA for critical systems development • UML basics, including extension mechanisms. • Extensions of UML (UMLsafe, UMLsec). • UML as a formal design technique. • MBRA and integrated system development processes. • Tools for UML: UMLsec and MBRA. • Case studies. Concentrate on security(-safety)-critical systems. Generalize to other application domains. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  8. Roadmap Prologue UML Safety Security Other relevant UML profiles MBRA and integrated SD processes Tool support Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  9. Using UML Unified Modeling Language (UML): • visual modeling language • different views on a system • allows for a high degree of abstraction • de-facto industry standard (OMG) • standard extension mechanisms Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  10. A Glimpse at UML Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  11. Used Fragment of UML Activity diagram: flow of control between system components Class diagram: data structure of the system Sequence diagram:interaction between components by message exchange Statechart diagram: dynamic component behavior Deployment diagram: components in physical environment Package:collect system parts into groups Current: UML 1.5 (released Mar 2003) Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  12. UML run–through: Activity diagrams • Specify the control flow between components within the system. • At a higher degree of abstraction than statecharts and sequence diagrams. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  13. UML run-through: Class diagrams • Data structure of system. • Components with attributes and operations/signals; relationships between components. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  14. UML run-through: Sequence Diagrams • Describe interaction between system components using message exchange. ] Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  15. UML run-through: Statecharts • Dynamic behavior of individual component. • Input events cause state change and output actions. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  16. UML run-through: Deployment diagrams • Describe the physical layer on which the system is to be implemented. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  17. UML run-through: Package • May be used to organize model elements into groups. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  18. UML Extension Mechanisms • Stereotype:specialize model element using <<label>>. • Tagged value:attach{tag=value} pair to stereotyped element. • Constraint:refine semantics of stereotyped element. • Profile:a particular set of stereotypes, tagged values and constraints. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  19. Roadmap Prologue UML Safety Security Other relevant UML profiles MBRA and integrated SD processes Tool support Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  20. Safety • Safety is freedom from accidents or losses [Leveson 1995]. • Safety-critical systems: five failure condition categories: catastrophic, hazardous, major, minor, no effect. • Corresponding safety levels A - E (DO-178B standards in avionics). • Safety goals: specified as the maximum allowed failure rate. For high degree of safety, testing not sufficient (1 failure per 100,000 years). Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  21. Failures Exchanged data may be • delayed (and possibly reordered) • lost • corrupted. Often, failures occur randomly (e.g. hardware). Failure semantics examples: • crash/performance: component may crash or exceed time limit, but still be partially correct. • value: component may deliver incorrect values. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  22. Fault-tolerance • Redundancy model determines which level of redundancy provided. • Goal: no hazards in presence of single-point failures. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  23. Embedded Systems Embedded software increasingly used in safetycritical systems (flexibility): • Automotive • Avionics • Aeronautics • Robotics, Telemedicine • … Our treatment of safety-critical systems also applies to embedded systems. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  24. UMLsafe: Goals Extensions for safe systems development. • evaluate UML specifications for weaknesses in design • encapsulate established rules of prudent safety engineering as checklist • make available to developers not specialized in safety-critical systems • consider safety from early design phases, in system context • make certification cost-effective Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  25. The UMLsafe Profile • Recurring safety requirements, failure scenarios, concepts (fault tolerance) offered as stereotypes with tags on component-level. • Use associated constraints to evaluate specifications and indicate possible weaknesses. • Ensures that UML specification provides desired level of safety. • Link to code via test-sequence generation. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  26. Failure Semantics Modeling For redundancy model R, stereotype s∊{<<crash/performance>>,<<value>>}, have set FailuresR(s)⊆{delay(t), loss(p), corrupt(q)}: • t: expected maximum time delay, • p: probability that value not delivered within t, • q: probability that value delivered in time corrupted (in each case incorporating redundancy). Or use <<risk>>stereotype with {failure} tag. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  27. Example Suppose redundancy model R uses controller with redundancy 3and the fastest result. Then could take: • delay(t): t delay of fastest controller, • loss(p): p probability that fastest result delivered within t, • loss(p): p probability that fastest result is corrupted. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  28. <<guarantee>> Describe guarantees required from communication dependencies for respective system components. Tags: {goal} with value subset of {immediate(t), eventual(p), correct(q)}, where • t: expected maximum time delay, • p: probability that value is delivered within t, • q: probability that value delivered in time not corrupted. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  29. <<safe links>> Physical layer should meet safety requirements on communication given redundancy model R. Constraint: For dependency d stereotyped <<guarantee>> have corresponding communication link l with stereotype s such that • if {goal} has immediate(t) as value then delay(t‘) FailuresR(s) implies t‘·t, • if {goal} has eventual(p) as value then loss(p‘) FailuresR(s) implies p‘·1-p, and • if {goal} has correct(q) as value then corruption(q‘) FailuresR(s) implies q‘·1-q. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  30. Example <<safe links>> Given redundancy model none, <<safe links>> fulfilled iff T· expected delay according to Failuresnone(<<crash/performance>>). Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  31. <<safe dependency>> Communication dependencies should respect safety requirements on <<critical>> data. For each safety level {l} for <<critical>> data, have goals(l)⊆{immediate(t), eventual(p), correct(q)}. Constraint: for each dependency dfrom C to D stereotyped <<guarantee>>: • Goals on data in D imply those in C. • Goals on data inC also appearing inDmet by guarantees of d. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  32. Example <<safe dependency>> Assuming immediate(t) goals(realtime), violates <<safe dependency>>, since Sensor and dependency do not provide real-time goal immediate(t) for measure() required by Controller. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  33. <<safe behaviour>> Ensures that system behavior in presence of failure model provides required safety {goals} by requiring that in any trace h of the execution: • immediate(t): Value delivered after at most t time steps. • eventual(p): Probability that delivered value is lost during transmission at most 1-p. • correct(q): Probability that delivered value corrupted during transmission at most 1-q. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  34. <<containment>> Prevent indirect corruption of data. Constraint: Value of any data element d may only be influenced by data whose requirements attached to <<critical>>imply those of d. Make precise by referring to execution semantics (view of history associated with safety level). Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  35. Example <<containment>> Violates containment because a {safe} value depends on un{safe} value. Can check this mechanically. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  36. Other Checks Have other consistency checks such as • Is the software‘s response to out-of-range values specified for every input ? • If input arrives when it shouldn't, is a response specified? …and other safety checks from the literature. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  37. Failure Models lqln: messages on link l delayed further n time units. phn: probability of failure at nth iteration in history h. For link l stereotyped s where loss(p)2FailuresR(s), • history may give lql0:=;; then append p to (phn)n2N, • or no change, then append 1-p. For link l stereotyped s where corruption(q)2FailuresR(s), • history may give lql0:=;; then append q, • or no change; append 1-q. For link l stereotyped s with delay(t)2FailuresR(s), and lql0;, history may give lqln:=lql0 for n·t; append 1/t . Then for each n, lqln:=lqln+1. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  38. Execution Semantics Behavioral interpretation of a UML subsystem: (1) Takes input events. (2) Events distributed from input and link queues between subcomponents to intended recipients where they are processed. (3) Output distributed to link or output queues. (4) Failure model applied as defined above. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  39. Roadmap Prologue UML Safety Security Other relevant UML profiles MBRA and integrated SD process Tool support Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  40. A Need for Security • Society and economies rely on computer networks for communication, finance, energy distribution, transportation... • Attacks threaten economical and physical integrity of people and organizations. • Interconnected systems can be attacked anonymously and from a safe distance. • Networked computers need to be secure. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  41. Problems • Many flaws found in designs of security-critical systems, sometimes years after publication or use. • Spectacular Example (1997): • NSA hacker team breaks into U.S. Department of Defence computers and the U.S.electric power grid system. Simulates power outages and 911 emergency telephone overloads in Washington D.C.. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  42. Causes I • Designing secure systems correctly is difficult. Even experts may fail: • Needham-Schroeder protocol (1978) • attacks found 1981 (Denning, Sacco), 1995 (Lowe). • Designers often lack background in security. • Security as an afterthought. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  43. Causes II • Cannot use security mechanisms „blindly“: • Security often compromised by circumventing (back doors)(rather than breaking) security mechanism. • Assumptions on system context, physical environment. • „Those who think that their problem can be solved by simply applying cryptography don`t understand cryptography and don`t understand their problem“ (Lampson, Needham). Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  44. Difficulties • Exploit information spreads quickly. • No feedback on delivered security from customers. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  45. Previous approaches „Penetrate-and-patch“: unsatisfactory. • insecure (damage until discovered) • disruptive (distributing patches costs money, destroys confidence, annoys customers). Traditional formal methods: expensive. • training people • constructing formal specifications. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  46. Goal: Security by Design Consider security • from early on • within development context • taking an expansive view • in a seamless way. Secure design by model analysis. Secure implementation by test generation. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  47. Holistic view on Security „An expansive view of the problem is most appropriate to help ensure that no gaps appear in the strategy“ (Saltzer, Schroeder 1975). But „no complete method applicable to the construction of large general-purpose systems exists yet“ - since 1975. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  48. From UMLsafe to UMLsec Safety = „Security against stupid adversaries“ Security = „Safety for paranoids“ Adversaries in security correspond to failures in safety. Replace failure model in UMLsafe by adversary model to get UMLsec. Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  49. UMLsec UMLsec: extension for secure systems development. • evaluate UML specifications of vulnerabilities • encapsulate security engineering patterns • also for developers not specialized in security • security from early design phases, in system context • make certification cost-effective Jürjens and Houmb: Critical System Development using MBRA and UMLsec

  50. The UMLsec profile • Recurring security requirements as stereotypes with tags (secrecy, integrity,...). • Associated constraints to evaluate model, indicate possible vulnerabilities. • Ensures that stated security requirements enforce given security policy. • Ensures that UML specification provides requirements. Jürjens and Houmb: Critical System Development using MBRA and UMLsec