Critical System Development using MBRA and UMLsec Methods

Critical System Development using MBRA and UMLsec: Methods and Tools Jan 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 Jan Jürjens, TU Munich: Critical Systems Development with UML

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 2

Quality vs. Cost • • Systems on which human life and commercial assets depend need careful development. Systems operating under possible system failure or attack need to be free 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 3

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

Using 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 5

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 6

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 7

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 8

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 9

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

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 11

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 12

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 13

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

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 15

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 16

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

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 18

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 19

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 178 B 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 20

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 21

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 22

Embedded Systems Embedded software increasingly used in safety critical 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 23

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 24

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 25

Failure Semantics Modeling For redundancy model R, stereotype s∊{<<crash/performance>>, <<value>>}, have set Failures. R(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 26

Example Suppose redundancy model R uses controller with redundancy 3 and 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 27

<<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 28

<<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‘) Failures. R(s) implies t‘·t, • if {goal} has eventual(p) as value then loss(p‘) Failures. R(s) implies p‘· 1 p, and • if {goal} has correct(q) as value then corruption(q‘) Failures. R(s) implies q‘· 1 q. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 29

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 30

<<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 d from C to D stereotyped <<guarantee>>: • Goals on data in D imply those in C. • Goals on data in C also appearing in D met by guarantees of d. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 31

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 32

<<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 33

<<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 34

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 35

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 36

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)2 Failures. R(s), • history may give lql 0: =; ; then append p to (phn)n 2 N, • or no change, then append 1 -p. For link l stereotyped s where corruption(q)2 Failures. R(s), • history may give lql 0: =; ; then append q, • or no change; append 1 -q. For link l stereotyped s with delay(t)2 Failures. R(s), and lql 0 ; , history may give lqln: =lql 0 for n·t; append 1/t. Then for each n, lqln: =lqln+1. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 37

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 38

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 39

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 40

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 41

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 42

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 43

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

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 45

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 46

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 47

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 48

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 49

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 50

Basic Security Requirements Secrecy Information Integrity Information Jürjens and Houmb: Critical System Development using MBRA and UMLsec 51

<<Internet>>, <<encrypted>>, … Kinds of communication links between respective system nodes. For adversary type A, stereotype s, have set Threats (s) ∊ {delete, read, insert, access} of actions that adversaries are capable of. Default attacker: Stereotype Threats () Internet encrypted LAN smart card {delete, read, insert} {delete} ∅ ∅ Jürjens and Houmb: Critical System Development using MBRA and UMLsec 52

Requirements with use case diagrams Capture security requirements in use case diagrams. Constraint: need to appear in corresponding activity diagram. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 53

<<fair exchange>> Ensures generic fair exchange condition. Constraint: after a {buy} state in activity diagram is reached, one will eventually reach {sell} state. (Cannot be ensured for systems that an attacker can stop completely. ) Jürjens and Houmb: Critical System Development using MBRA and UMLsec 54

Example <<fair exchange>> Customer buys goods from a business. Fair exchange means: after payment, customer is eventually either delivered good or able to reclaim payment. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 55

<<secure links>> Ensures that physical layer meets security requirements on communication. Constraint: for each dependency d with stereotype s ∊ {<<secrecy>>, <<integrity>>} between components on nodes n≠m, have a communication link l between n and m with stereotype t such that • if s = <<secrecy>>: have read ∉ Threats (t). • if s = <<integrity>>: have insert ∉ Threats (t). Jürjens and Houmb: Critical System Development using MBRA and UMLsec 56

Example <<secure links>> • Given default adversary type, constraint for stereotype <<secure links>> violated: – According to the Threatsdefault(Internet) scenario, <<Internet>> link does not provide secrecy against default adversary. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 57

<<secure dependency>> Ensure that <<call>> and <<send>> dependencies between components respect security requirements on communicated data given by tags {secrecy}, {integrity}. Constraint: for <<call>> or <<send>> dependency from C to D (and similarly for {secrecy}): • Msg in D is {secrecy} in C if and only if also in D. • If msg in D is {secrecy} in C, dependency stereotyped <<secrecy>>. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 58

Example <<secure dependency>> • Violates <<secure dependency>>: – Random generator and <<call>> dependency do not give security level for random() to key generator. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 59

<<no down–flow>> Enforce secure information flow. Constraint: • Value of any data specified in {secrecy} may influence only the values of data also specified in {secrecy}. • Formalize by referring to formal behavioral semantics. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 60

Example <<no down flow>> • <<no down–flow>> violated: – partial information on input of high wm() returned by non high rx(). Jürjens and Houmb: Critical System Development using MBRA and UMLsec 61

<<data security>> Security requirements of data marked <<critical>> enforced against threat scenario from deployment diagram. Constraints: • Secrecy of {secrecy} data preserved. • Integrity of {integrity} data preserved. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 62

Example <<data security>> Variant of TLS (INFOCOM`99). Violates {secrecy} of s against default adversary. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 63

<<guarded access>> Ensures that in Java, <<guarded>> classes only accessed through {guard} classes. Constraints: • References of <<guarded>> objects remain secret. • Each <<guarded>> class has {guard} class. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 64

Example <<guarded access>> • Provides <<guarded access>>: – Access to Mic. Si protected by Mic. Gd. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 65

Concepts covered by UMLsec Security requirements: <<secrecy>>, … Threat scenarios: Use Threatsadv(ster). Security concepts: e. g. <<smart card>>. Security mechanisms: e. g. <<guarded access>>. Security primitives: Encryption built in. Physical security: Given in deployment diagrams. Security management: Use activity diagrams. Technology specific: Java, CORBA security. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 66

Security Analysis • Model classes of adversaries. • May attack different parts of the system according to threat scenarios. • Example: insider attacker may intercept communication links in LAN. • To evaluate security of specification, simulate jointly with adversary model. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 67

Applications • Common Electronic Purse Specifications • Analysis of multi layer security protocol for web application of major German bank • Analysis of SAP access control configurations for major German bank • Risk analysis of critical business processes (for Basel II / Kontra. G) • … Jürjens and Houmb: Critical System Development using MBRA and UMLsec 68

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 69

Real time: UMLreal • Similar to dependability. • Usually the focus is on meeting hard time deadlines. • Add special stereotypes for this in UMLreal. • Can also use this with the UML RT extension. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 70

Real time: UML RT • UML extended with concepts from the ROOM modelling language (Selic, Rumbaugh 1998). • Focus on software architecture. • New: capsules, ports, connectors. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 71

UML RT: capsules, ports, connectors Capsules: architectural objects interacting through signal based boundary objects (ports). Port: object implementing interface of capsule. Associated with a protocol defining flow of information. Connector: abstract signal based communication channels between ports. Functionality of capsule realized by associated state machine. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 72

Example From Selic, Rumbaugh 1998. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 73

Quality of service: UMLqos • Similar to dependability. • Usually the focus is on measuring the time delay on communication lines. • Special stereotypes for this purpose. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 74

Hybrid Systems • Actions define the discontinuities (instantaneous actions performed by combinational part). • Activities define the smooth periods (the time consuming behavior of the analog part while combinational part is idle). Jürjens and Houmb: Critical System Development using MBRA and UMLsec 75

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 76

Model Based Risk Assessment • Integrated process – Make use of system models both as system description and as input to risk assessment • Support reuse (and ease the updating of system description during and after assessment) • Cost efficient (at the right time for the right cost) • Precise specification of security requirements – security requirements using UMLsec – existing security mechanism using CORAS UML profile or SOL – results from assessment using CORAS UML profile or SOL (Security assessment Object Language). Jürjens and Houmb: Critical System Development using MBRA and UMLsec 77

Development processes/ Life Cycle Models • IEC 61508: Functional safety of electrical/electronic/programmable electronic safety related systems. • RUP (Rational Unified Process) or more general UP. • CORAS integrated RMP and SDP. • Integrated risk assessment and system development process for networked enterprises. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 78

IEC 61508 (1) The strategy of the standard is to derive safety requirements from a hazard and risk analysis and to design the system to meet those safety requirements, taking all possible causes of failure into account [IEC 61508]. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 79

Jürjens and Houmb: Critical System Development using MBRA and UMLsec 80

IEC 61508 (3) • Concept: An understanding of the system and its environment is developed. • Overall scope definition: The boundaries of the system and its environment are determined, and the scope of the hazard and risk analysis is specified. • Hazard and risk analysis: Hazards and hazardous events of the system, the event sequences leading to the hazardous events, and the risks associated with the hazardous events are determined. • Overall safety requirements: The specification for the overall safety requirements is developed in order to achieve the required functional safety. • Safety requirements allocation: The safety functions contained in the overall safety requirements specification are allocated to the safety related system, and a safety integrity level is allocated to each safety function. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 81

IEC 61508 (4) • Overall operation and maintenance planning: A plan is developed for operating and maintaining the system, and the required functional safety is ensured to be maintained during operation and maintenance. • Overall safety validation planning: A plan for the overall safety validation of the system is developed. • Overall installation and commissioning planning: Plans, ensuring that the required functional safety is achieved, are developed for the installation and commissioning of the system. • Safety related systems, E/E/PES: The E/E/PES safety related system is created conforming to the safety requirements specification. • Safety related systems, other technology: Other technology safety related systems are created to meet the requirements specified for such systems (outside scope of the standard). Jürjens and Houmb: Critical System Development using MBRA and UMLsec 82

IEC 61508 (5) • External risk reduction facilities: External risk reduction facilities are created to meet the requirements specified for such facilities (outside scope of the standard). • Overall installation and commissioning: The E/E/PES safety related system is installed and commissioned. • Overall safety validation: The E/E/PES safety related system is validated to meet the overall safety requirements specification. • Overall operation, maintenance and repair: The system is operated, maintained and repaired in order to ensure that the required functional safety is maintained. • Overall modification and retrofit: The functional safety of the system is ensured to be appropriate both during and after modification and retrofit. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 83

IEC 61508 (6) • Decommissioning or disposal: The functional safety of the system is ensured to be appropriate during and after decommissioning or disposing of the system. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 84

Integrate SD and RM process (1) • Emphasize on handling risk at the right time for the right price (as early as possible). • Make use of MBRA and use models both to describe the system and as input to RA. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 85

Integrate SD and RM process (2) Jürjens and Houmb: Critical System Development using MBRA and UMLsec 86

Benefits • • • Cost efficient (saving is the game…). An integrated part of the development. Detailed guidelines. Make use of UML (industry standard). Time efficient. Supports continuously decision making processes (risk management). Jürjens and Houmb: Critical System Development using MBRA and UMLsec 87

Secure Development of Embedded Systems • Integrated system development and risk management process. • Based on IEC 61508 and CORAS. • Using UML to capture non functional requirements (security and safety). • Using UML for design. • Using UML to document results from risk management. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 88

Prototype System of a Production Cell Jürjens and Houmb: Critical System Development using MBRA and UMLsec 89

Requirements for UML based Development Processes • Use UML all the way through the process. • Consistent use of UML by everyone involved (profile? ). • Models need to be consistent – Top down approach with guidelines on how to transfer information between UML models (preliminary) – Bottom up approach – Make use of both top down and bottom up approach (as for risk analysis of critical systems). Jürjens and Houmb: Critical System Development using MBRA and UMLsec 90

UML based SD: Experience • See appendix • Categories of use of UML: • Fri use of UML • UML use regulated by guidelines • Requires use of a UML tool and a specific set of guidelines with automatic documentation generation and requirements tracking with the use of the UML tool Requires use of a specific UML tool and a specific set of guidelines with complete code generation (includes requirements tracking) and automatic generation of documentation Jürjens and Houmb: Critical System Development using MBRA and UMLsec 91

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 92

Tool support: Concepts Meaning of diagrams stated informally in (OMG 2003). Ambiguities problem for • tool support • establishing behavioral properties (safety, security). Need precise semantics for used part of UML, especially to ensure security requirements. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 93

Formal semantics for UML • Diagrams in context (using subsystems). • Model actions and internal activities explicitly. • Message exchange between objects or components (incl. event dispatching). • Include failure/adversary model arising from physical environment in deployment diagram. • Use Abstract State Machines (pseudo code). Jürjens and Houmb: Critical System Development using MBRA and UMLsec 94

Tool supported analysis • Choose drawing tool for UML specifications. • Commercial modeling tools: so far mainly syntactic checks and code generation. • Analyze specifications via XMI (XML Metadata Interchange). Jürjens and Houmb: Critical System Development using MBRA and UMLsec 95

UML Drawing Tools Wide range of existing tools. Consider some, selected under following Criteria (Shabalin 2002): • Support for all (UMLsec ) relevant diagram types. • Support for custom UML extensions. • Availability (test version, etc). • Prevalence on the market. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 96

Selected Tools • Rational Rose. Developed by major participant in development of UML; market leader. • Visio for Enterprise Architect. Part of Microsoft Developer Studio. NET. • Together. Often referenced as one of the best UML tools. • Argo. UML. Open Source Project, therefore interesting for academic community. Commercial variant Poseidon. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 97

Comparison Evaluated features: Support for custom UML extensions. • Model export; standards support; tool interoperability. • Ability to enforce model rules, detect errors, etc. • User interface quality. • Possibility to use the tool for free for academic institutions. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 98

Rational Rose (Rational Software Corporation) One of the oldest on the market. + Free academic license. + Widely used in the industry. + Export to different XMI versions. Insufficient support for UMLextensions (custom stereotypes yes; tags and constraints no). Limited support for checking syntactic correctness. Very inconvenient user interface. Bad layout control. Lack of compatibility between versions and with other Rational products for UML modeling. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 99

Together from Together. Soft Widely used in the development community. Very good round trip engineering between the UML model and the code. + Free academic license. + Written in Java, therefore platform independent. + Nice, intuitive user interface. + Export to different XMI versions; recommendations which for which tool. Insufficient support for UML extensions (custom stereotypes yes; tags and constraints no). Jürjens and Houmb: Critical System Development using MBRA and UMLsec 100

Visio from Microsoft Corporation Has recently been extended with UML editing support. + Good user interface. + Full support for UML extensions. + Very good correspondence to UML standard. Checks dynamically for syntactic correctness; suggestions for fixing errors. No free academic license. Proprietary, undocumented file format; no export to XMI or other tools. No round trip engineering support. No way back after code generation. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 101

Argo. UML / Poseidon Argo. UML: Open Source Project. Commercial extension Poseidon (Gentleware), same internal data format. + Open Source. + Written in Java, therefore platform independent. + XMI default model format. + Solid mature product with good UML specification support. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 102

Tool supported analysis Commercial modeling tools: so far mainly syntactic checks and code generation. Goal: more sophisticated analysis; connection to verification tools. Several possibilities: • General purpose language with integrated XML parser (Perl, …) • Special purpose XML parsing language (XSLT, …) • Data Binding (Castor; XMI: e. g. MDR) Jürjens and Houmb: Critical System Development using MBRA and UMLsec 103

Data binding with MDR • Extracts data from XMI file into Java Objects, following UML 1. 4 meta model. • Access data via methods. • Advantage: No need to worry about XML. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 104

Definition • MDR = Meta. Data Repository – Load and Store a MOF Metamodel – Instantiate and Populate a Metamodel – Generate a JMI (Java Metadata Interface) Definition for a Metamodel – Access a Metamodel Instance Jürjens and Houmb: Critical System Development using MBRA and UMLsec 105

UML Processing Jürjens and Houmb: Critical System Development using MBRA and UMLsec 106

MDR Standards • MOF (Meta Object Facility) Abstract format for describing metamodels • XMI (XML Metadata Interchange) Defines XML format for a MOF metamodel • JMI (Java Metadata Interface) Defines mapping from MOF to Java Jürjens and Houmb: Critical System Development using MBRA and UMLsec 107

MOF Architecture • Metamodel (M 3) – defined by OMG • Metamodels (M 2) – user defined – e. g. UML 1. 5, MOF, CWM – can be created with uml 2 mof • Business Model (M 1) – instances of Metamodels – e. g. UML class diagram • Information (M 0) – instance of model – e. g. implementation of UML modelled classes in Java Jürjens and Houmb: Critical System Development using MBRA and UMLsec 108

MOF (Meta Object Facility) OMG Standard for Metamodeling Metamodel Model Data Meta. Class, Meta. Association MOF Model Class, Attribute, Dependency UML (as language), CWM Person, House, City UML model (Bob Marley, 1975) (Bonn) Running Program Jürjens and Houmb: Critical System Development using MBRA and UMLsec 109

JMI: MOF Interfaces • IDL mapping for manipulating Metadata – API for manipulating information contained in an instance of a Metamodel – MOF is MOF compliant! – Metamodels can be manipulated by this IDL mapping – JMI is MOF to Java mapping – JMI has same functionality • Reflective APIs – manipulation of complex information – can be used without generating the IDL mapping – MDR has implemented these interfaces Jürjens and Houmb: Critical System Development using MBRA and UMLsec 110

Netbeans MDR Explorer • • • Part of Netbeans IDE Browse Repositories Create Instances Load XMI Data Generate JMI Interfaces • Shows – Extents – Metamodels – Instances Jürjens and Houmb: Critical System Development using MBRA and UMLsec 111

MDR Repository: Loading Models • Metamodel is instance of another Metamodel • Loading Model = Loading Metamodel • Needed Objects: – MDRepository – Mof. Package – XMISax. Reader. Impl • Java Code Snippet: MDRepository rep; Uml. Package uml; // Objekte erzeugen: rep = MDRManager. get. Default(). get. Default. Repository(); reader = (XMISax. Reader. Impl)Lookup. get. Default(). lookup( Xmi. Reader. class); // loading extent: uml = (Uml. Package)rep. get. Extent(„name“); // creating Extent: uml = (Uml. Package)rep. create. Extent(„name“); // loading XMI: reader. read(„url“, Mof. Package); , Jürjens and Houmb: Critical System Development using MBRA and UMLsec 112

MDR Repository: Reading Data • Requires open • Example: Loading Repository and Package UML Class: • Requires JMI Interfaces Iterator it = • Problem: where is the uml. get. Core(). get. Uml. Class( data I need? ). ref. All. Of. Class(). iterator (); • To find Objects: – open Model in MDR Explorer – browse to the desired Element – use the getter Functions to retrieve the element while (it. has. Next()) { Uml. Class uc = (uml. Class)it. next(); //. . do anything with Uml. Class. . } Jürjens and Houmb: Critical System Development using MBRA and UMLsec 113

Connection with analysis tool Industrial CASE tool with UML like notation: AUTOFOCUS (http: //autofocus. • • informatik. tu muenchen. de) Simulation Validation (Consistency, Testing, Model Checking) Code Generation (e. g. Java, C, Ada) Connection to Matlab Connect UML tool to underlying analysis engine. Jürjens and Houmb: Critical System Development using MBRA and UMLsec 114

Jürjens and Houmb: Critical System Development using MBRA and UMLsec 115

Some resources Book: Jan Jürjens, Secure Systems Development with UML, Springer Verlag, due 2003. Follow on Tutorials: June: UMLws (SFO); Sept: FME (Pisa), FDL (Frankfurt), SAFECOMP (Edinburgh), Nov: LADC 2003(Sao Paulo) Special So. Sy. M issue on Critical Systems Development with UML More information (slides etc. ): http: //www 4. in. tum. de/~juerjens/csdumltut (user: Participant, password: Iwasthere) Jürjens and Houmb: Critical System Development using MBRA and UMLsec 116

Finally We are always interested in industrial challenges for our tools, methods, and ideas to solve practical problems. See http: //www 4. in. tum. de/~juerjens Contact me here or via Internet. Thanks for your attention ! Jürjens and Houmb: Critical System Development using MBRA and UMLsec 117