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
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…
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…
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
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?
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
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)
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.
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.
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.
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
65. ICTSS 2010PhD DefencePhu Hong NGUYEN 65
Recap MDS with Reusability: SoSPa – a System of
Security Design Patterns for Systematically
Engineering Security Systems.
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.
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.
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?