Model-Driven Security with Modularity and Reusability for Engineering Secure Software Systems
•Télécharger en tant que PPTX, PDF•
3 j'aime•1,013 vues
PhD defence
Recommandé
Recommandé
Contenu connexe
Similaire à Model-Driven Security with Modularity and Reusability for Engineering Secure Software Systems
Similaire à Model-Driven Security with Modularity and Reusability for Engineering Secure Software Systems (20)
Plus de Phu H. Nguyen
Plus de Phu H. Nguyen (9)
Dernier
Dernier (20)
Model-Driven Security with Modularity and Reusability for Engineering Secure Software Systems
- 1. Model-Driven Security with Modularity and Reusability for Engineering Secure Software Systems PhD Defence, September 10th, 2015 Candidate: Phu Hong Nguyen PhD Candidate, University of Luxembourg, Luxembourg Committee: Dr. Yves Le Traon (Supervisor) Professor, University of Luxembourg, Luxembourg Dr. Pierre Kelsen (Chair) Professor, University of Luxembourg, Luxembourg Dr. Jacques Klein (Vice-Chair) Senior Research Scientist, University of Luxembourg, Luxembourg Dr. Jörg Kienzle (External Reviewer) Professor, McGill University, Montréal, Canada Dr. Riccardo Scandariato (External Reviewer) Professor, Chalmers University of Technology and University of Gothenburg, Sweden
- 2. ICTSS 2010PhD DefencePhu Hong NGUYEN 2 Why do we care about the security of software systems?
- 3. ICTSS 2010PhD DefencePhu Hong NGUYEN 3 What a nice car! But what is scary here?
- 4. ICTSS 2010PhD DefencePhu Hong NGUYEN 4 Opps, a driver totally lost control of his car on the high way because someone successfully hacked the car’s software remotely…
- 5. ICTSS 2010PhD DefencePhu Hong NGUYEN 5 Humans in the Loop of Security-Critical Systems
- 6. ICTSS 2010PhD DefencePhu Hong NGUYEN 6 software complexity increases exponentially where business complexity increases linearly. (Glass, 2002) (IfM and IBM, 2008) -- www.capgemini.com dbstrat.com Challenge 1: (Software) systems are getting more complex.
- 7. ICTSS 2010PhD DefencePhu Hong NGUYEN 7 securesoftware.blogspot.com Challenge 2: Security concerns are not often taken into account early in the development process!
- 8. ICTSS 2010PhD DefencePhu Hong NGUYEN 8 http://blogs.vmware.com Challenge 3: Economic pressure reduces the development time…
- 9. ICTSS 2010PhD DefencePhu Hong NGUYEN 9 How to tackle these challenges?
- 10. ICTSS 2010PhD DefencePhu Hong NGUYEN 10 http://www.theenterprisearchitect.eu/blog/2009/08/05/a-metaphor-for-model-driven-engineering/JOHAN DEN HAAN Model-Driven Engineering (MDE)
- 11. ICTSS 2010PhD DefencePhu Hong NGUYEN 11 http://www.theenterprisearchitect.eu/blog/2009/08/05/a-metaphor-for-model-driven-engineering/JOHAN DEN HAAN Model-Driven Security (MDS)
- 12. ICTSS 2010PhD DefencePhu Hong NGUYEN 12 www.sparxsystems.com MDE & MDS: more productive, supposedly less error-prone.
- 13. ICTSS 2010PhD DefencePhu Hong NGUYEN 13 Model-Driven Security with SecureUML Model Driven Security, Technical Report 414, ETH Zurich, 2004 SecureUML MDS: Security concerns are dealt with from the very beginning, and throughout the development cycle.
- 14. ICTSS 2010PhD DefencePhu Hong NGUYEN 14 http://matt.might.net/articles/phd-school-in-pictures/ More than a decade of Model-Driven Security research: what MDS approaches been proposed, what issues are open to be researched? MDE MDS
- 15. ICTSS 2010PhD DefencePhu Hong NGUYEN 15 • A Systematic Literature Review of MDS Main Content • Model-Driven Security with Modularity • Model-Driven Security with Reusability
- 16. ICTSS 2010PhD DefencePhu Hong NGUYEN 16
- 17. ICTSS 2010PhD DefencePhu Hong NGUYEN 17 www.replicatedtypo.com Why an Extensive Systematic Review of MDS?
- 18. ICTSS 2010PhD DefencePhu Hong NGUYEN 18 Automatic Search Process & Selection of MDS papers. *Search range: 2002-2014
- 19. ICTSS 2010PhD DefencePhu Hong NGUYEN 19 “Snowballing” for a complete set of primary MDS papers: 108 finally selected.
- 20. ICTSS 2010PhD DefencePhu Hong NGUYEN 20 Classified Synthesized ComparedAnalyzed
- 21. ICTSS 2010PhD DefencePhu Hong NGUYEN 21 Significant MDS approaches vs. Less common or emerging MDS approaches.
- 22. ICTSS 2010PhD DefencePhu Hong NGUYEN 22 1. The lack of addressing multiple security concerns systematically.
- 23. ICTSS 2010PhD DefencePhu Hong NGUYEN 23 2. Aspect-Oriented Modelling (AOM) should be promoted more.
- 24. ICTSS 2010PhD DefencePhu Hong NGUYEN 24 Model transformations & Code generation => 3. MDS tool chain based on automated model transformations is rare.
- 25. ICTSS 2010PhD DefencePhu Hong NGUYEN 25 Next Goal 1: Towards an MDS tool chain from modelling to testing. Next Goal 2: How to address multiple security concerns more systematically? Next Goal 3: How to leverage AOM techniques to better enhance separation-of-concern in the MDS development process?
- 26. ICTSS 2010PhD DefencePhu Hong NGUYEN 26
- 27. ICTSS 2010PhD DefencePhu Hong NGUYEN 27 Towards an MDS tool chain: from modelling to testing.
- 28. ICTSS 2010PhD DefencePhu Hong NGUYEN 28 Access Control (AC): Administering access to resources by enforcing AC policy. www.redsandz.com
- 29. ICTSS 2010PhD DefencePhu Hong NGUYEN 29 Delegation of right(s) allows a user (delegator) to delegate her/his access right(s) to another user (delegatee). www.jjdigeronimo.com
- 30. ICTSS 2010PhD DefencePhu Hong NGUYEN 30 Yves (Professor) delegates his signature for using budget to Jacques (Senior Research Scientist) while Yves is on vacation. www.loxton.com.sg
- 31. ICTSS 2010PhD DefencePhu Hong NGUYEN 31 http://www.masterminditservices.com http://www.techcommandos.com Another delegation instance: File Sharing
- 32. ICTSS 2010PhD DefencePhu Hong NGUYEN 32 Yves (Professor) delegates his signature for using budget to Jacques (Senior Research Scientist) while Yves is on vacation and automatically gets it back after his vacation. www.loxton.com.sgTemporary Delegation
- 33. ICTSS 2010PhD DefencePhu Hong NGUYEN 33 www.loxton.com.sg Transfer Delegation Yves (Professor) delegates his signature to Jacques (Senior Research Scientist) AND Yves is not allowed to use his signature while delegating it.
- 34. ICTSS 2010PhD DefencePhu Hong NGUYEN 34 Yves (Professor) delegates his signature to Jacques (Senior Research Scientist) BUT Jacques is not allowed to delegate it to anyone else. www.loxton.com.sg Multi-Step Delegation
- 35. ICTSS 2010PhD DefencePhu Hong NGUYEN 35 Yves (Professor) is not allowed to delegate his signature to any PhD student. www.loxton.com.sg Non-Delegable
- 36. ICTSS 2010PhD DefencePhu Hong NGUYEN 36
- 37. ICTSS 2010PhD DefencePhu Hong NGUYEN 37 Hidden Mechanism Problems
- 38. ICTSS 2010PhD DefencePhu Hong NGUYEN 38 Proposed Solution: Separation of concerns among Business Logic / Access Control / Delegation
- 39. ICTSS 2010PhD DefencePhu Hong NGUYEN 39 Access control metamodel Access policy Architecture metamodel Base model Model composition Security- enforced architecture model Self adaptation 000 Running system Proxy ComponentsProxy components Adaptive execution platform validation change/evolution evolution evolution M2 M1 M0 test Proxy componentsProxy componentsBusiness logic components Delegation metamodel Delegation policy Active security policy Model transformation test conforms to (cft) cft cft cft cft Modelling Security Concerns and Business Logic
- 40. ICTSS 2010PhD DefencePhu Hong NGUYEN 40 Access control metamodel Access policy Architecture metamodel Base model Model composition Security- enforced architecture model Self adaptation 000 Running system Proxy ComponentsProxy components Adaptive execution platform validation change/evolution evolution evolution M2 M1 M0 test Proxy componentsProxy componentsBusiness logic components Delegation metamodel Delegation policy Active security policy Model transformation test conforms to (cft) cft cft cft cft Composing
- 41. ICTSS 2010PhD DefencePhu Hong NGUYEN 41 Access control metamodel Access policy Architecture metamodel Base model Model composition Security- enforced architecture model Self adaptation 000 Running system Proxy ComponentsProxy components Adaptive execution platform validation change/evolution evolution evolution M2 M1 M0 test Proxy componentsProxy componentsBusiness logic components Delegation metamodel Delegation policy Active security policy Model transformation test conforms to (cft) cft cft cft cft Code Generation (and Adaptation)
- 42. ICTSS 2010PhD DefencePhu Hong NGUYEN 42 Bill is transferring his rights to Bob
- 43. ICTSS 2010PhD DefencePhu Hong NGUYEN 43 Transform & adapt Resource Proxy Components Role Proxy Components User Proxy Components Business Components Access Control policy Business Logic model Authenticate Component Adaptive Execution Platform Business Components Business Logic Components Resource Proxy Components Role Proxy Component s User Proxy Components Delegation policy Test cases Access Control policy Mutants Mutants Mutants Mutate Compose Testing Delegation Policy Enforcement via Mutation Analysis
- 44. ICTSS 2010PhD DefencePhu Hong NGUYEN 44 Recap MDS with Modularity: Model-Driven Adaptive Delegation and Mutation Testing.
- 45. ICTSS 2010PhD DefencePhu Hong NGUYEN 45
- 46. ICTSS 2010PhD DefencePhu Hong NGUYEN 46 How to address multiple security concerns more systematically? How to leverage AOM techniques to better enhance separation-of-concern in the MDS development process? www.enterprisearchitects.com
- 47. ICTSS 2010PhD DefencePhu Hong NGUYEN 47 Kienzle et al., Crisis management systems: a case study for aspect-oriented modeling, TAOSD VII, pages 1-22, 2010 How to systematically design the security of Crisis Management Systems (CMS)?
- 48. ICTSS 2010PhD DefencePhu Hong NGUYEN 48 Kienzle et al., Crisis management systems: a case study for aspect- oriented modeling, TAOSD VII, pages 1-22, 2010 CMS - A complex, distributed system but must be secure.
- 49. ICTSS 2010PhD DefencePhu Hong NGUYEN 49 Security Patterns could be the solution but…
- 50. ICTSS 2010PhD DefencePhu Hong NGUYEN 50 Using a catalog of security patterns improves neither the productivity of the software designer, nor the security of the design.
- 51. ICTSS 2010PhD DefencePhu Hong NGUYEN 51 We need more: bridge the gap of abstract security patterns with their detailed designs, their application, especially their interrelations. Authentication Enforcer pattern
- 52. ICTSS 2010PhD DefencePhu Hong NGUYEN 52 • Security design patterns are specified as reusable aspect models. • A refinement process from abstract design patterns to detailed security design patterns. • Inter-pattern guides in systematically selecting the right security design patterns for the job. SOLUTION: An MDS approach based on a library- like System of Security design Patterns (shortly called SoSPa).
- 53. ICTSS 2010PhD DefencePhu Hong NGUYEN 53 Aspect Session pattern SOLUTION: Security Patterns are specified as Reusable Aspect Models.
- 54. ICTSS 2010PhD DefencePhu Hong NGUYEN 54 Extended RAM metamodel to support SoSPa
- 55. ICTSS 2010PhD DefencePhu Hong NGUYEN 55 Feature model for specifying the interrelations among security patterns.
- 56. ICTSS 2010PhD DefencePhu Hong NGUYEN 56 Interrelations among the security patterns
- 57. ICTSS 2010PhD DefencePhu Hong NGUYEN 57 A partial feature model of Authentication.
- 58. ICTSS 2010PhD DefencePhu Hong NGUYEN 58
- 59. ICTSS 2010PhD DefencePhu Hong NGUYEN 59
- 60. ICTSS 2010PhD DefencePhu Hong NGUYEN 60 • Security threats identification & analysis • Security design patterns selection and application – Step 1: Constructing security solutions from the security patterns in SoSPa – Step 2: Defining mappings to integrate the newly built security solutions to a base system model – Step 3: Weaving the security solutions into the base system model • Verification & validation of security patterns application Pattern-Driven Secure Systems Development Process
- 61. ICTSS 2010PhD DefencePhu Hong NGUYEN 61 A partial view of CMS with part of the createMission function.
- 62. ICTSS 2010PhD DefencePhu Hong NGUYEN 62 Selected security design patterns for building the security solution for CMS.
- 63. ICTSS 2010PhD DefencePhu Hong NGUYEN 63 Woven model: The woven class diagram of CMS including security patterns’ classes. Woven Model
- 64. ICTSS 2010PhD DefencePhu Hong NGUYEN 64 Woven Model
- 65. ICTSS 2010PhD DefencePhu Hong NGUYEN 65 Recap MDS with Reusability: SoSPa – a System of Security Design Patterns for Systematically Engineering Security Systems.
- 66. ICTSS 2010PhD DefencePhu Hong NGUYEN 66
- 67. ICTSS 2010PhD DefencePhu Hong NGUYEN 67 Summary 1: An Extensive Systematic Review on the Model-Driven Development of Secure Systems.
- 68. ICTSS 2010PhD DefencePhu Hong NGUYEN 68 Summary 2: MDS with Modularity for Dynamic Adaptation of Secure Systems.
- 69. ICTSS 2010PhD DefencePhu Hong NGUYEN 69 Summary 3: MDS with Reusability – a System of Security design Patterns for Systematically Engineering Secure Systems.
- 70. ICTSS 2010PhD DefencePhu Hong NGUYEN 70
- 71. ICTSS 2010PhD DefencePhu Hong NGUYEN 71 • Develop MDS Tool Chains. • Extend SoSPa: Impact Model, Testing. • Combining SoSPa approach with Delegation?
- 72. ICTSS 2010PhD DefencePhu Hong NGUYEN 72 http://www.u-test.eu Another direction: Security Modelling and Model- Based Security Testing of Cyber-Physical Systems under Uncertainty.
- 73. ICTSS 2010PhD DefencePhu Hong NGUYEN 73 Publications: Systematic Review and Advanced in MDS 1. Phu Hong Nguyen, Max E. Kramer, Jacques Klein, and Yves Le Traon. ``An Extensive Systematic Review on the Model-Driven Development of Secure Systems." In Information and Software Technology, 2015. 2. Phu Hong Nguyen, Jacques Klein, Yves Le Traon, and Max E. Kramer. ``A Systematic Review of Model-Driven Security." In Software Engineering Conference (APSEC, 2013 20th Asia-Pacific, vol. 1, pp. 432-441. IEEE, 2013. 3. Levi Lucio, Qin Zhang, Phu Hong Nguyen, Moussa Amrani, Jacques Klein, Hans Vangheluwe, and Yves Le Traon. ``Advances in Model- Driven Security." Advances in Computers 93 (2014): 103-152.
- 74. ICTSS 2010PhD DefencePhu Hong NGUYEN 74 Publications: MDS with Modularity 4. Phu Hong Nguyen, Gregory Nain, Jacques Klein, Tejeddine Mouelhi, and Yves Le Traon. ``Modularity and Dynamic Adaptation of Flexibly Secure Systems: Model-Driven Adaptive Delegation in Access Control Management." In Transactions on Aspect-Oriented Software Development XI, pp. 109-144. Springer Berlin Heidelberg, 2014. 5. Phu Hong Nguyen, Gregory Nain, Jacques Klein, Tejeddine Mouelhi, and Yves Le Traon. ``Model-driven adaptive delegation." In Proceedings of the 12th annual international conference on Aspect- oriented software development, pp. 61-72. ACM, 2013. 6. Phu Hong Nguyen, Mike Papadakis, and Iram Rubab. ``Testing Delegation Policy Enforcement via Mutation Analysis." In Software Testing, Verification and Validation Workshops (ICSTW), 2013 IEEE Sixth International Conference on, pp. 34-42. IEEE, 2013.
- 75. ICTSS 2010PhD DefencePhu Hong NGUYEN 75 Publications: MDS with Reusability 7. Phu Hong Nguyen, Koen Yskout, Thomas Heyman, Jacques Klein, Riccardo Scandariato, and Yves Le Traon. “SoSPa: A System of Security Design Patterns for Systematically Engineering Secure Systems.” In ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems. 2015. 8. Phu Hong Nguyen, Jacques Klein, and Yves Le Traon. ``Model- Driven Security with A System of Aspect-Oriented Security Design Patterns." In 2nd Workshop on View-Based, Aspect-Oriented and Orthographic Software Modelling. 2014.
- 76. ICTSS 2010PhD DefencePhu Hong NGUYEN 76
- 77. Model-Driven Security with Modularity and Reusability for Engineering Secure Software Systems PhD Defence, September 10th, 2015 Candidate: Phu Hong Nguyen PhD Candidate, University of Luxembourg, Luxembourg Committee: Dr. Yves Le Traon (Supervisor) Professor, University of Luxembourg, Luxembourg Dr. Pierre Kelsen (Chair) Professor, University of Luxembourg, Luxembourg Dr. Jacques Klein (Vice-Chair) Senior Research Scientist, University of Luxembourg, Luxembourg Dr. Jörg Kienzle (External Reviewer) Professor, McGill University, Montréal, Canada Dr. Riccardo Scandariato (External Reviewer) Professor, Chalmers University of Technology and University of Gothenburg, Sweden
Notes de l'éditeur
- Welcome to my PhD defence presentation about how Model-Driven Security with Modularity and Reusability can help building secure software systems. This is nearly 4 years of my PhD work that I am presenting in 45 minutes. I will tell you why I have done this research; what I have done in my PhD work; and summarize the contributions of my thesis. Let me begin with the motivation why I have been doing this research… about software security engineering.
- Is it enough to convince you that we need to care a lot about the security of software systems? If not yet, let’s move on…
- You can see an electric car but very powerful, a smart car, highly wirelessly connected (to the internet). What a nice car! I took a photo of the big touchable screen inside the car last month in Norway when I had a chance to drive this car. What is scary here??? Assuming that you don’t surf webs or google while driving. Good news is that you cannot open Youtube videos while driving, I tried… If you are a “good” driver, what is still scary here???
- Oopss, someone could hijack remotely your car on the highway! Uconnect, the Internet-connected software installed in newer Fiat Chrysler models, can be hacked remotely due to a vulnerability in its cellular capabilities. Luckily this is only an experiment. This is just an example to show that Software is getting a bigger share in controlling system/network over hardware. Hot trends now: Software-Defined Networking (SDN) CPS But, controllers are computers prone to bugs and attacks. But, any failure e.g. in security, could lead to physical damages, involving human in where Cyber Physical Systems are getting popular.
- CPS is going to be everywhere: Transportation, Military, Health Care, Infrastructure, Energy, Communication, etc. More importantly, CPS often involve humans who can physically interact with the systems. The security of computer systems and networks cannot be ensured by only enhancing network security and other perimeter solutions. It is also essential for ensuring security by building better, secure software . But why building secure systems is so hard???so challenging? From engineering point of view, there could be three main challenges in building modern secure software systems. Antivirus programs, network security, etc. are important but not enough! The security of the software systems itself is also very important, i.e. to allow the genius users of the system to work efficiently but prevent any malicious attackers to exploit or harm the system.
- The first challenge: complexity.
- The second challenge: we all know the later security is taken into account the much worse damages are. But security concerns are not often taken into account early.
- 3. Economic pressure reduces the development time and increases the frequency of demanded modifications… Developing complex software takes time but if not fast enough, the product would be obsolete regarding business…
- How to tackle these 3 challenges? => MDE, MDS. Why MDE, Why MDS Contributing to the design state. Proven solution to early design
- - Proven solution to early design - More productive with automation Supposedly less error-prone
- MDS is a specialization of MDE for developing secure software systems. All security concerns are taken into account early, with security solutions are integrated into the model of the system.
- The models of security solutions are integrated into the model of system under development to create “MDS-Model”. The MDS-Model can be used in a formal verification process, in a model-based testing process, as well as generating source code of the system including security infrastructures.
- What are the open issues to be further investigated? My PhD work first must know what are the open issues in the state-of-the-art of MDS, and then what we could contribute to the research domain to broaden the knowledge boundary…
- Thus, first we conducted a systematic literature review of MDS. Then we present our work on two main directions to contribute to this research domain: MDS with Modularity and Reusability.
- Let’s start with the systematic review
- To know what we could contribute in MDS that no one else has done, a good survey of MDS would be enough. But we could do better than that: a systematic literature review (SLR)! Why? As can be seen in the concept of a SLR, the primary studies selected after a rigorous, less-biased selection process are reviewed in a systematic way to have a systematic view of the research domain/sub-domain. The results of the SLR allow us to see a big picture of the research domain (MDS) with the main “players” or research methodologies and the missing areas that are open for new contributions in the field.
- Our rigorous search process to find primary MDS publications started with the manual search process in which we selected 80 primary MDS papers out of 10633 relevant papers.
- The manual search process still has some limitations in providing a complete set of primary MDS papers. To complement for the results of automatic search, we also conducted a manual search process in 10 high-impact journals and 10 conference proceedings in more than 10 years to find out 29 primary MDS papers. After merging the two set of 80 and 29, we have 95 MDS papers. To improve and have more confidence about the completeness in the final set of primary MDS papers, a “snowballing” process was employed where we recursively searched for new MDS papers by looking for new primary MDS papers in the references and citations of the already selected primary MDS papers. Finally, we ended up with 108 primary MDS papers for systematically reviewing and analyzing the results.
- The data from 108 primary MDS papers were extracted, classified, synthesized, analyzed, and compared to give the results for the study.
- Among the main results of our SLR, we have found out all the significant MDS approaches (such as SecureUML, UMLsec, SECTET) as well as emerging/less common MDS approaches (such as AOM4MDS, MDS@runtime, Pattern-based MDS). In the context of this PhD work, we focused on tackling the following three of the main challenges in the state-of-the-art of MDS research backed up by our SLR.
- First, we aim at tackling the lack of addressing multiple security concerns systematically in MDS research. The Ven diagram shows that only about 10% of primary MDS papers address three most common security concerns, i.e. Authorisation, Authentication, and Confidentiality. If we count also other concerns such as Integrity and Accountability together with the former three, there are very few MDS approaches deal with all of them, and not systematically, i.e. interrelations among security concerns and solutions are considered.
- RQ3: What are the open issues to be further investigated?
- 1 step only
- Thanks to Reusability we can address multiple security concerns…
- MOTIVATION 3: Security patterns based on domain-independent, time-proven security knowledge & expertise but not applied sufficiently Catalogs of security patterns are the most accessible, well documented resources of different security solutions for different security concerns BUT not enough! the results of two relevant empirical studies [260, 261] have shown that using existing catalogs of security patterns does neither improve the productivity of the software designer, nor the security of the design. Interrelationships among security concerns have to be considered. Most MDS approaches have separation-of-concerns but not fully/truly AOM. Using fully/truly AOM improves the modularity and reusability, and also make MDS better works with other NFRs. Security patterns are not applied as much as they could be because developers have problems in selecting them and applying them in the right places, especially at the design phase.
- Diagram
- RQ3: What are the open issues to be further investigated?
- RQ3: What are the open issues to be further investigated?
- RQ3: What are the open issues to be further investigated?