Systematic Development of UMLsec Design Models Based On Security Requirements

Transcription

1 and Systematic Development of UMLsec Design Models Based On Security Requirements European Joint Conferences on Theory and Practice of Software (ETAPS) Fundamental Approaches to Software Engineering Denis Hatebur 1,2, Maritta Heisel 2, Jan Jürjens 3,4, and Holger Schmidt 1,3 1 ITESYS Inst. f. Tech. Sys. GmbH, Germany 2 University Duisburg-Essen, Faculty of Engineering, Department of Computational and Applied Cognitive Science, SE, Germany 3 TU Dortmund, Faculty of Computer Science, SE, Germany 4 Fraunhofer ISST, Germany 1/ 21

2 Motivation and Goal and 2/ 21 Goal Developing security-critical systems Transition from security requirements analysis to UMLsec [Jür05] design models Problem Informal guidelines Our Approach Formal guideline Model generation rules expressed as pre- and postconditions in Object Constraint Language (OCL) [UML06] Specification of CASE tool

3 Security Requirements Analysis and Environment Awareness Requirements describe the environment after the software is in action [Jac01]. Security describes the inability of the environment to have an undesirable effect on a technical system [RTLN06]. Modeling the environment is essential for secure software engineering Security requirements analysis [H06, H07] based on Jackson s problem frames [Jac01] UML profile UML4PF 1 supporting Jackson s approach 3/

4 UMLsec Design Models and UMLsec [Jür05] UML profile for modeling security-critical systems Support for different kinds of security properties via stereotypes and tagged values Support for different kinds of UML diagram types such as deployment, class, and sequence diagrams UMLsec analysis tools 2 Static checks, permission analysis, integration of external verification tools, code generation 4/

5 Overview and : security requirements analysis based on UML4PF : Environment models Structural and behavioral specification of security mechanisms : design models enriched with UMLsec stereotypes further analysis using UMLsec analysis tools possible 5/ 21

6 Environment Description of PMS and : Patient Monitoring System (PMS) Environment model as UML4PF class diagram Environment structured by means of domains and shared phenomena 6/ 21

7 Functional Requirements of PMS and No Requirement refersto constrains R1 R2 R3 The vital signs should be displayed, and an alarm should be raised if the vital signs exceed the limits. The infusion flow is controlled according to the configured doses for the current vital signs. Configura- Patient, tion PhysiciansAndNurses Configura- Patient, tion Physicians and nurses can change the configuration. Terminal Configuration InfusionPump 7/ 21

8 Security Requirements of PMS and No Security Statement complements 1 Configuration should be protected from modification for Patient against Attacker or PhysiciansAndNurses should be informed. 2 Alarm and Vital Signs should be protected from modification for Patient against Attacker or PhysiciansAndNurses should be informed. 3 Configuration, Alarm, and Vital Signs should be protected from disclosure for Patient against Attacker. R2 refersto Configuration is asset, Terminal and WLAN know asset, Patient is stakeholder, against Attacker R1 Alarm and Vital Signs are assets, Terminal and WLAN know asset, Patient is stakeholder, against Attacker R1, R2 Configuration, Alarm, and Vital Signs are assets, Patient is stakeholder, against Attacker constrains / Mechanism TerminalDisplay/ MAC of SSL TerminalDisplay/ MAC of SSL WLAN/ encryption of SSL 4 The Shared Keys should be distributed to Terminal and PMS (for Patient) and Attacker should not be able to access Shared Keys. R1, R2 Shared Keys are assets, Patient is stakeholder, against Attacker WLAN/ key exchange of SSL (KE) 8/ 21

9 Security Domain Knowledge of PMS and No Security Statement complements 1 The KE keys should be distributed to Terminal and PMS for Patient, and Attacker should not be able to access Shared Keys. 2 Infusion Flow and PatientMonitoringSystem should be protected from modification for Patient against Attacker or Patient should know. 3 Infusion Flow and PatientMonitoringSystem should be protected from disclosure for Patient against Attacker. 4 Terminal should be protected from modification for Patient against Attacker or PhysiciansAndNurses should know. refersto R1, R2 KE keys are assets, Patient is stakeholder, against Attacker R1, R2, R3 R1, R2, R3 Infusion Flow and Patient- Monitoring- System are assets, Patient is stakeholder, against Attacker Infusion Flow and Patient- Monitoring- System are assets, Patient is stakeholder, against Attacker R1, R2 Terminal is asset, Patient is stakeholder, against Attacker constrains / Mechanism WLAN/ manual import in physically protected area Infusion Pump, PatientMonitoring- System/ physical protection (e.g., EMF) and protection by Patient Infusion Pump, PatientMonitoring- System/ physical protection (e.g., EMF) and protection by Patient Terminal/ physical protection (e.g., EMF) and protection by PhysiciansAndNurses 9/ 21

10 From Security Requirements to Secure Design and Concept: Design decisions through interactive model generation Model generation rules expressed as OCL pre- and postconditions OCL specifications for UMLsec deployment, class, and sequence diagrams Technical realization: Papyrus UML 3 Relating UML4PF stereotypes to UMLsec stereotypes Patterns for security mechanisms 10/

11 Generating UMLsec Deployment Diagrams and 1 createdeploymentdiagram ( PMS Deployment ) ; 2 a d d S e c u r e L i n k s S t e r e o t y p e ( PMS Deployment, d e f a u l t ) ; 3 c r e a t e N o d e s ( PMS Deployment ) ; 4 c r e a t e N e s t e d C l a s s e s ( { C o n f i g u r a t i o n } ) ; 5 g e t N e t w o r k C o n n e c t i o n s ( ) ; r e t u r n s { PMS! { Alarm, V i t a l S i g n s },T! { c o n f i g } } 6 c r e a t e C o m m u n i c a t i o n P a t h s ( PMS Deployment ) ; 7 setcommunicationpathtype ( PMS Deployment, PMS! { Alarm, V i t a l S i g n s }, T! { c o n f i g }, e n c r y p t e d ) ; 8 c r e a t e D e p e n d e n c i e s ( PMS Deployment ) ; 11/ 21

12 : Creating a UMLsec Deployment Diagram for PMS I createdeploymentdiagram( PMS Deployment ); and 12/ 21

13 : Creating a UMLsec Deployment Diagram for PMS II addsecurelinksstereotype( PMS Deployment, default ); and 13/ 21

14 : Creating a UMLsec Deployment Diagram for PMS III and 1 a d d S e c u r e L i n k s S t e r e o t y p e ( diagramname : S t r i n g, adv : S t r i n g ) 2 PRE package w i t h name diagramname e x i s t s 3 Package. a l l I n s t a n c e s ( ) >s e l e c t ( name=diagramname ) 4 >s i z e ( )=1 and 5 ( adv = d e f a u l t or adv = i n s i d e r ) 6 POST Package. a l l I n s t a n c e s ( ) >s e l e c t ( name=diagramname ) 7. g e t A p p l i e d S t e r e o t y p e s ( ). name >i n c l u d e s ( s e c u r e l i n k s ) and 8 Package. a l l I n s t a n c e s ( ) >s e l e c t ( name=diagramname ) 9. g e t V a l u e ( Package. a l l I n s t a n c e s ( ) >s e l e c t ( name=diagramname ) 10. g e t A p p l i e d S t e r e o t y p e s ( ) 11 >s e l e c t ( s. oclastype ( S t e r e o t y p e ). name >i n c l u d e s ( s e c u r e l i n k s ) ) 12 >assequence ( ) > f i r s t ( ), a d v e r s a r y ) 13. oclastype ( S t r i n g ) >i n c l u d e s ( adv ) User interface to guarantee preconditions 14/ 21

15 : Creating a UMLsec Deployment Diagram for PMS IV createnodes( PMS Deployment ); and 15/ 21

16 : Creating a UMLsec Deployment Diagram for PMS V createnestedclasses ({ Configuration }) ; and 16/ 21

17 : Creating a UMLsec Deployment Diagram for PMS VI and getnetworkconnections(); returns { PMS!{Alarm,VitalSigns},T!{config} } createcommunicationpaths( PMS Deployment ); setcommunicationpathtype( PMS Deployment, PMS!{Alarm,VitalSigns}, T!{config }, encrypted ) ; 17/ 21

18 : Creating a UMLsec Deployment Diagram for PMS VII createdependencies( PMS Deployment ); and 18/ 21

19 : UMLsec Class Diagram for PMS and createkeyexchangeprotocol( Terminal, PatientMonitoringSystem, KeyExchProt ) «data security» PMS KeyExchProt «critical» Terminal S_: Data s_: Data N_: Data K_T: Keys inv(k_t): Keys K_CA: Keys i: Integer + resp(shrd, cert) «data security» adversary = default «critical» secrecy = {s_,inv(k_t)} integrity = {s_,n_,k_t,inv(k_t),k_ca,i} authenticity = (k,p_i) «primitivetype» Data «send, secrecy, integrity» «send, secrecy, integrity» «primitivetype» Keys «critical» secrecy = {inv(k_p),k_} integrity = {K_P,inv(K_P),K_CA,k_,j} «critical» PatientMonitoringSystem K_P: Keys inv(k_p): Keys K_CA: Keys k_: Keys j: Integer + init(n, k, cert) + xchd(mstr) «primitivetype» Expressions 19/ 21

20 : UMLsec Sequence Diagram for PMS and createkeyexchangeprotocol( Terminal, PatientMonitoringSystem, KeyExchProt ) sd PMS KeyExchProt Terminal init(n_i,k_t,sign(inv(k_t),t::k_t)) resp({sign(inv(k_p_i),k_j::n'::k'_t)}_k'_t, Sign(inv(K_CA),P_i::K_P_i)) PatientMonitoringSystem [snd(ext (K'_T,c_c))=K'_T] [fst(ext (K_CA),c_S=S_i) and snd(ext (K'_S_i,Dec(inv (K_T),c_k)))=N_i] xchd({s_i}_k) 20/ 21

21 and : Approach to bridge the gap between security requirements analysis and secure design Formal model generation rules Creating design models in the security domain becomes more routine and less error-prone. Future work: Develop a notion of correctness for the considered transition. Construct CASE tool. 21/ 21

22 I and [H06] Denis Hatebur, Maritta Heisel, and Holger Schmidt. Security engineering using problem frames. In G. Müller, editor, Proceedings of the International Conference on Emerging Trends in Information and Communication Security (ETRICS) (LNCS 3995), pages Springer, [H07] Denis Hatebur, Maritta Heisel, and Holger Schmidt. A pattern system for security requirements engineering. In Proceedings of the International Conference on Availability, Reliability and Security (AReS), pages IEEE Computer Society, / 21

23 II and [Jac01] [Jür05] Michael Jackson. Problem Frames. Analyzing and structuring software development problems. Addison-Wesley, Jan Jürjens. Secure Systems Development with UML. Springer, , 4 23/ 21

24 III and [RTLN06] Lillian Røstad, Inger Anne Tøndel, Maria B. Line, and Odd Nordland. Safety vs. security. In Michael G. Stamatelatos and Harold S. Blackman, editors, Proceedings of the International Conference on Probabilistic Safety Assessment and Management (PSAM). ASME Press, New York, [UML06] UML Revision Task Force. Object Constraint Language Specification. Object Management Group (OMG), May / 21