1. Secure Systems Research Group - FAU Model Checking Techniques for Security Systems 5/14/2009 Maha B Abbey PhD Candidate

2. Secure Systems Research Group - FAU Model-based Security Engineering using UMLsec Model-based Security Engineering –Approach for developing security critical software –Security requirements secrecy, integrity, authenticity …. –Security assumptions –UML specification

3. Secure Systems Research Group - FAU Model-based Security Engineering

4. Secure Systems Research Group - FAU UMLSec Secure system development Allows evaluation of UML specifications for vulnerability Using UML extension mecahnism –Formulate security requirements and assumptions Stereotypes Tags –Constraints used to determine whether the requirements are met by system design

5. Secure Systems Research Group - FAU UMLSec - Stereotypes Security assumptions on the physical system level, for example the stereotype «encrypted», when applied to a link in a UML deployment diagram, states that this connection has to be encrypted. Security requirements on the logical level, for example related to the secure handling and communication of data, such as «secrecy» or «integrity». Security policies that system parts are required to obey, such as «fair exchange» or Security assumptions on the physical system level, for

6. Secure Systems Research Group - FAU UMLSec tools framework

7. Secure Systems Research Group - FAU UMLSec Tool Support Used to check constraints associated with UMLSec stereotypes based on UML diagrams output (XMI) Verification routines for constraints associated with UMLSec stereotypes Use of UML state machine and UML-type communication mechanism important security requirements such as secrecy, integrity, authenticity, and secure information flow are defined secrecy, integrity, authenticity, and secure information flow are preserved under refinement and the composition of system components

8. Secure Systems Research Group - FAU UMLSec and patterns UMLsec can be used to specify and implement security patterns is supported by dedicated secure systems development processes, in particular an Aspect-Oriented Modeling approach which separates complex security mechanisms (which implement the security aspect model) from the core functionality of the system (the primary model) in order to allow a security verification of the particularly security-critical parts, and also of the composed model. [Jur04]

9. Secure Systems Research Group - FAU Safety Analysis [Cho07] easy-to-use formal approach for safety analysis in the early stage of requirements engineering in the context of component-based software development the issue of providing safety analysis capability while maintaining flexibility and usability is addressed by using semi-formal use cases with templates, which can be systematically translated into a formal specification language RSML-e. Verification of safety requirements is performed on the translated use cases using the model checker NuSMV integrated into the execution environment of RSML-e the issue of incorporating the result of the safety analysis into the early stage of design is addressed by defining a systematic transition from use cases to the high-level component design based on the KobrA approach

10. Secure Systems Research Group - FAU RSML-e Requirements State Machine Language without events state machine language designed with an emphasis on readability and writability for non-computer scientists, whose practical value has been proven through industrial applications the simple syntax of the language allows a systematic mapping from use cases to RSML-e its execution environment Nimbus provides automated visual simulation and formal verification capabilities. Once use cases are translated into RSML-e, validation of the use cases using simulation and formal safety analysis with the help of model checking are rather straightforward analysis result is incorporated into the system model by providing systematic transition from use cases to high-level component design consists of 7 basic constructs: input variables, state variables, input interface, output interface, functions, macros, and constants. –Input variables are used to record the values observed in the environment –state variables are organized in a hierarchical fashion and are used to model various states of the control model –interfaces act as communication gateways to the external environment –the function and macros encapsulate computations providing increased readability and ease of use

11. Secure Systems Research Group - FAU Use Cases Template specify behavioral requirements of software systems intuitive style which can be easily understood by engineers as well as non-technical stakeholders consist of three artifacts –use case diagrams –textual descriptions of use cases –use case scenarios illustrate the relationship among use cases and actors, giving an overview of the system behavior adopt a semi-formal template for textual use case description in order to support formal safety analysis with some degree of automation template is designed to specify details of use case behavior, including pre and post-conditions of the use case, the flow of events, and controlled (output) and/or monitored (input) variables related to the use case use case diagrams and use case templates focus on what the system does and not on how it implements

12. Secure Systems Research Group - FAU COMPONENT DESIGN FROM USE CASES use case specifications are used to derive a high level component design –The system under development defines a high-level abstract component class viewing the whole system as one component. –Each actor identified in the use case diagram defines a class associated with the component class. –Each controlled variable defines an attribute of the component class. –Each use case that has a direct interaction with an external actor defines an externally visible operation of the component. –Each include/extending/specialized use case without direct interaction with an external actor defines an operation of a sub-component of the component. –Each monitored variable for each use case defines a parameter of the corresponding operation. –A set of associations between an actor and use cases defines an interface. The internal behavior (realization) of each externally visible system operation is described using an activity/interaction diagram

13. Secure Systems Research Group - FAU SAFETY ANALYSIS USING MODEL CHECKING Use cases are converted into the operations of high-level design with their behavior specified in the textual use cases and use case scenarios are manifested into the component realization any unsafe behavior of the use cases can propagate into high- level components, and then, to lower-level components because of the recursive nature of the approach the identification of safety-related issues in use cases is a must so that we can take the issues under consideration throughout the transition and decomposition process most unsafe situations result from inter-dependent but under- specified use cases, which makes manual analysis difficult especially when we have a large number of use cases automated analysis approach using model checking by systematically translating use cases to the formal specification language RSML-e, enables to use the simulation and verification tools integrated into the execution environment of RSML-e, facilitating an easy access to formal verification method

14. Secure Systems Research Group - FAU Verification Framework

15. Secure Systems Research Group - FAU Safety Analysis how to support systematic and easy-to- use analysis methods on semi-formal use cases –formal specification language RSML-e for its intuitive syntax and semantics as well as its execution environment enabling automated verification how to incorporate prevention mechanisms into the design stage based on the analysis result –guidelines for seamless transition from use cases to the initial component design, which is recursively decomposed in the design process

16. Secure Systems Research Group - FAU Some References [Che02] Hao Chen, David Wagner, “MOPS: an infrastructure for Examining Security Properties of Software”, CCS’02 [Jur05] J. Jurjens, “Sound Methods and Effective Tools for Model-based Security Engineering with UML”, 27th International Conference on Software Engineering (ICSE 2005), ACM, 2005, 322--331. [Fer06a] E. B. Fernandez, M.M. Larrondo-Petrie, T. Sorgente, and M. VanHilst, "A methodology to develop secure systems using patterns", Chapter 5 in "Integrating security and software engineering: Advances and future vision", H. Mouratidis and P. Giorgini (Eds.), IDEA Press, 2006, 107-126. [Bes07] B. Best, J. Jurjens and B. Nuseibeh, Model-based Security Engineering of Distributed Information Systems using UMLsec, Procs. 29th International Conference on Software Engineering (ICSE 2007), ACM, 2007, 581—590 [Jur04] J. Jürjens. Secure Systems Development with UML.Springer- Verlag, 2004. [Cho07] Yunja Choi: "Early Safety Analysis: from Use Cases to - Component-based Software Development", in Journal of Object Technology, vol. 6, no. 8, September - October 2007, 185-203 http://www.jot.fm/issues/issue_2007_09/article4. http://www.jot.fm/issues/issue_2007_09/article4

17. Secure Systems Research Group - FAU Feedback TLS Pattern (How to establish authentication) – Concrete version ->SSL –How is the analysis done? Example UMLSec RSML Vs RSML-e Perform comparison of both methods with examples (Use same example such as Elevator)

18. Secure Systems Research Group - FAU Feedback