1. Model-Driven Architecture And The Secure Systems Methodology Masters Thesis Defense 11/16/2007 Patrick Morrison

2. Agenda ► Introduction ► Problem statement ► Approach ► Contribution ► Related Work ► What is MDA? ► Experiment ► Results ► Conclusions ► Future Work

3. The problem of Security ► “A good percentage of the software deployed in industrial/commercial applications is of poor quality, it is unnecessarily complex, and contains numerous flaws that can be exploited by attackers.” ► “We believe that the solution lies in developing secure software from the beginning, applying security principles along the whole life cycle…We see the use of patterns as a fundamental way, even for developers with little experience, to implicitly apply security principles.” ► [Fer06a, EBF, et. al.]

4. Security Patterns

5. Secure Systems Methodology [Fer06a] StageTasksRequirements Use case and activity diagram based role and attack analysis Analysis Class and sequence diagrams, preferring semantic analysis patterns Design Application of design patterns across architectural layers Implementation Mapping design on to selected technical architecture

6. Methodology Claim, paraphrased ► [by using] “abstract and graphical representations of patterns, the methodology allows the construction of secure computing systems from patterns which aid developers in understanding much more quickly and deeply than programming language “code”

7. MDA Claim ► [by using] “precise but abstract and graphical representations of algorithms, MDA allows the construction of computing systems from models that can be understood much more quickly and deeply than can programming language “code” [Mel04]. [

8. Problem ► Can Model-Driven Architecture (MDA) be used to support the secure systems methodology?  To what degree is it now possible to work in terms of high-level models rather than code?  Does MDA allow for the creation and reuse of generic models?  Does MDA reduce the amount of low-level work that needs to be done? ► What would be required to gain these benefits?

9. Approach ► Establish an MDA tool-chain ► Select an example distributed systems security problem ► Apply the advice of the secure systems methodology to the construction of models for the example system for each lifecycle phase ► Evaluate MDA models against example’s properties and their use in the lifecycle.

10. Contribution ► A set of models of secure shell (ssh) corresponding to the phases of the secure systems methodology ► An example MDA tool chain that translates UML Classes into Java source code. ► A set of considerations for applying MDA

11. Related Work ► SecureUML – Models RBAC for web applications ► UMLSec – Models security analysis for existing systems ► Executable UML – automated code generation from UML models, no explicit focus on security ► SysML- modeling notation for systems engineering ► UML Profile for RM-ODP – distributed systems standard, including security considerations ► RSML – process control requirements specification language ► Tropos – Agent-oriented methodology

12. What is MDA? ► A set of technologies: UML, MOF, XMI, OCL ► A model-centric framework for systems development ► A set of viewpoints ► A scheme for transforming models to to other models, and to text (code)

13. MDA Technologies ► UML2 – a language and notation for building models ► MOF – a language for building modeling languages, beginning with UML2 ► XMI – a persistence mechanism for MOF, allowing exchange between tools ► QVT – a transformation language for MOF models ► OCL – a language for expressing logical assertions on MOF models, e.g. UML2

14. MDA Models and Metamodels

15. MDA Viewpoints ► Computation-Independent Models (CIM) contain domain concepts ► Platform-Independent Models (PIM) define a technology-independent view of the system ► Platform-Specific Models (PSM) contain system descriptions including technology aspects ► Platform – the technical architecture of a given system

16. MDA Transformations

17. MDA Transformations, example public class Subject { public String id; } public class Object { public String id; public String id;} public class Right { public String id; public String id; public String access_type; public String access_type; public Boolean copy_flag; public Boolean copy_flag; public Subject s; public Subject s; public Object o; public Object o;} «IMPORT metamodel» «DEFINE javaClass FOR Entity» «FILE name+".java"» public class «name» { «FOREACH attributes AS attr» public «attr.type» «attr.name»; «ENDFOREACH» «FOREACH references AS ref» public «ref.type.name» «ref.name»; «ENDFOREACH» } «ENDFILE» «ENDDEFINE»

18. MDA Concepts, in UML

19. MDA Tool-chain ► UML Editor, Model creation, XMI generation  MagicDraw ► Model-to-Model, Model-to-Text transformation  openArchitectureWare ► Target Platform  Java ► Integration  Eclipse

20. Experiment ► Apply secure systems methodology to building models for abstract version of remote access ► Reverse-engineer SSH design models from architecture documents and source code ► Compare analysis results to SSH architecture ► Evaluate ability of MDA to assist in translation of models from phase N to phase N+1:  Requirements -> Analysis  Analysis -> Design

21. Example: Remote Access

22. Example(2): Secure Shell (SSH) ► Widely used network protocol providing security for remote access to user accounts and similar services ► [SSH] “enables secure remote login and other secure network services over an insecure network”  server authentication  client authentication (public key, password, host-based)  confidentiality  Integrity  perfect forward security. ► Well-documented:  Internet standard: RFC’s 4250-6 describe goals, architecture  Open source client implementation: Ganymed SSH-2 for Java

23. Requirements: Use Cases

24. Requirements: Sequence Diagram

25. Requirements: Activity Diagram

26. Analysis: Initial Class Diagram

27. Patterns applied during Analysis ► Authenticator ► Known Partners ► Single Access Point ► Checkpoint ► Security Session ► Information Obscurity ► Secure Channels

28. Analysis: Final Class Diagram

29. Compare: SSH Transport Protocol (reverse engineered from RFC)

30. Analysis Result ► Application of standard security patterns to the abstract case of remote access yielded a reasonably comprehensive model of the entities and relationships that participate in the SSH architecture.

31. Results ► Application of the methodology to a generic version of the example problem yielded a model that corresponds well to an existing solution of the problem ► Models captured fragments of the system from a given viewpoint, in this case depending on the lifecycle phase ► The ability to connect entities between phases depends on a shared metamodel ► No such metamodel exists for the presented models

32. Results(2), Questions revisited ► To what degree is it now possible to work in terms of high-level models rather than code?  Within constraints, there are opportunities to work with models rather than code ► Does MDA allow for the creation and reuse of generic models?  Insufficient evidence collected to support answering this question. ► Does MDA reduce the amount of low-level work that needs to be done?  MDA increases the amount of work required to build the first application.

33. Conclusions ► Requirements, Analysis and Design are fundamentally about deciding what you want, while MDA excels in describing what you have. ► Conclusion: MDA can be useful when working with a known domain and a known architecture. ► Metamodels, and transformations on them, are MDA’s driving force. Where they exist or their creation is justified, they can assist in the development process

34. Conclusions(2) ► MDA is not a good fit for a methodology; but it could be a good fit for an instance of a methodology. ► MDA can capture the details of domain and architecture, allowing systems designers to concentrate on variations within an established framework. ► This does suggest that software alteration and maintenance may be enhanced by the use of MDA

35. Future Work ► Develop Java platform model to support code generation from existing analysis models ► Choose second, third example applications ► Map examples on to suitable metamodel(s)  Unify lifecycle phase models  Factor out application, secuirty, platform dependencies  Evaluate existing metamodels: SysML, RM-ODP ► Encode security pattern knowledge in the metamodel

36. Committee ► Dr. E.B. Fernandez ► Dr. Shihong Huang ► Dr. Maria Petrie