DEPARTMENT OF COMPUTER SCIENCE
MODELING DECEPTION FOR CYBER SECURITY
CRISTIANO DE FAVERI Master in Computer Science
DOCTORATE IN COMPUTER SCIENCE
NOVA University Lisbon
COMPUTER SCIENCE
MODELING DECEPTION FOR CYBER SECURITY
CRISTIANO DE FAVERI Master in Computer Science
Adviser: Ana Maria Diniz Moreira
Associated Professor with Habilitation, NOVA School of Science & Technology
Examination Committee:
Chair: Luís Manuel Marques da Costa Caires
Full Professor, NOVA School of Science & Technology
Rapporteurs: Neil Charles Rowe
Full Professor, U.S. Naval Postgraduate School
Marcos Kalinowski
Associated Professor, Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
Adviser: Ana Maria Diniz Moreira
Associated Professor with Habilitation, NOVA School of Science &
Technology
Members: Awais Rashid
Full Professor, University of Bristol
Ademar Aguiar
Associated Professor, University of Porto
Vasco Miguel Moreira do Amaral
Associated Professor, NOVA School of Science & Technology
DOCTORATE IN COMPUTER SCIENCE NOVA University Lisbon
Modeling Deception for Cyber Security
Copyright © Cristiano De Faveri, NOVA School of Science and Technology, NOVA Univer- sity Lisbon.
The NOVA School of Science and Technology and the NOVA University Lisbon have the right, perpetual and without geographical boundaries, to file and publish this dissertation through printed copies reproduced on paper or on digital form, or by any other means known or that may be invented, and to disseminate through scientific repositories and admit its copying and distribution for non-commercial, educational or research purposes, as long as credit is given to the author and editor.
A c k n o w l e d g e m e n t s
It has been a long journey! And just now, at the end, I expresses what matters the most: my gratitude to those who helped me reaching this far. First and foremost, to my advisor Ana Moreira, my deepest gratitude for her time, guidance, patient, and insightful comments and reviews throughout the whole span of this research work. I have no words to thank Ana for her generosity, kindness, and friendship. I am honoured for the opportunity to learn from such a brilliant and respected computer scientist. My gratitude to Ana’s family (José, Tomi, and Mel) for sharing their time with me on several occasions and for welcom- ing my family and I, making us feel at ease in Portugal. A special thanks to my Thesis committee members, Awais Rashid and Henrique João, for their challenging questions and helpful insights. My gratitude to the Automated Software Engineering (ASE) group, Vasco Amaral, Miguel Monteiro, Miguel Goulão, Jácome Cunha, and João Araújo. I thank Professor Eduardo Piveta for assisting me in the first steps of this PhD project. Thank you also to the host and funding institutions, NOVA University of Lisbon, NOVA LINCS (Ref.
UID/CEC/04516/2013), BE MUNDUS Project and CAPES Foundation (Ref. 0553/14-0).
I thank all my labmates for the discussions, sharing the coffee machine, feeding the fish automatically, and having installed colored wifi bulbs in our lab, which gave it a fortunate psycoledic appearance recognized by the entire campus. I miss you all: Catarina Gralha, João Cambeiro, Eric Rocha, Fernando Wanderley, Denise Bombonatti, Lyrene Silva, Juan Vidal, Ankica Barišić, Denis Silveira, Eliane Loiola, Juliana Dantas, Charlie Lopes, Enyo Tavares, and Elias Adriano. To my dear Portuguese buddies, Ines, João, Filipa, and Hugo, thank you for the wine-driven rides at Bairro Alto and your unwavering support over the years. You have a special place in my heart. I would like to express my gratitude to my parents Antonio and Edemée (in memoriam) for providing me with an education and ideals. To my little boy, Murillo, whose abundant happiness makes me strong every single day. Also, I thank Germano for accepting the challenge of being away from home.
Finally, I owe a debt of gratitude to my dear wife, Thais. I would not be able to complete this dissertation without her unconditional support. Her sweet soul was always there to comfort me when the rigors of mental endeavor cast a shade. Thank you for always being there for me. I love you to the moon and back.
–Voltaire
A b s t r a c t
In the era of software-intensive, smart and connected systems, the growing power and so- phistication of cyber attacks poses increasing challenges to software security. The reactive posture of traditional security mechanisms, such as anti-virus and intrusion detection systems, has not been sufficient to combat a wide range of advanced persistent threats that currently jeopardize systems operation. To mitigate these extant threats, more ac- tive defensive approaches are necessary. Such approaches rely on the concept of actively hindering and deceiving attackers. Deceptive techniques allow for additional defense by thwarting attackers’ advances through the manipulation of their perceptions. Manipu- lation is achieved through the use of deceitful responses, feints, misdirection, and other falsehoods in a system. Of course, such deception mechanisms may result in side-effects that must be handled. Current methods for planning deception chiefly portray attempts to bridge military deception to cyber deception, providing only high-level instructions that largely ignore deception as part of the software security development life cycle. Con- sequently, little practical guidance is provided on how to engineering deception-based techniques for defense. This PhD thesis contributes with a systematic approach to specify and design cyber deception requirements, tactics, and strategies. This deception approach consists of(i)a multi-paradigm modeling for representing deception requirements, tac- tics, and strategies, (ii)a reference architecture to support the integration of deception strategies into system operation, and(iii)a method to guide engineers in deception mod- eling. A tool prototype, a case study, and an experimental evaluation show encouraging results for the application of the approach in practice. Finally, a conceptual coverage map- ping was developed to assess the expressivity of the deception modeling language created.
Keywords:Deception-based Security, Requirements Engineering, Adaptive Software Ar- chitectures, Multi-paradigm Modeling, Domain-Specific Modeling Languages.
Na era digital o crescente poder e sofisticação dos ataques cibernéticos apresenta constan- tes desafios para a segurança do software. A postura reativa dos mecanismos tradicionais de segurança, como os sistemas antivírus e de detecção de intrusão, não têm sido suficien- tes para combater a ampla gama de ameaças que comprometem a operação dos sistemas de software actuais. Para mitigar estas ameaças são necessárias abordagens ativas de defesa. Tais abordagens baseiam-se na ideia de adicionar mecanismos para enganar os adversários (do inglêsdeception). As técnicas de enganação (em português, "ato ou efeito de enganar, de induzir em erro; artimanha usada para iludir") contribuem para a defesa frustrando o avanço dos atacantes por manipulação das suas perceções. A manipula- ção é conseguida através de respostas enganadoras, de "fintas", ou indicações erróneas e outras falsidades adicionadas intencionalmente num sistema. É claro que esses meca- nismos de enganação podem resultar em efeitos colaterais que devem ser tratados. Os métodos atuais usados para enganar um atacante inspiram-se fundamentalmente nas técnicas da área militar, fornecendo apenas instruções de alto nível que ignoram, em grande parte, a enganação como parte do ciclo de vida do desenvolvimento de software seguro. Consequentemente, há poucas referências práticas em como gerar técnicas de defesa baseadas em enganação. Esta tese de doutoramento contribui com uma aborda- gem sistemática para especificar e desenhar requisitos, táticas e estratégias de enganação cibernéticas. Esta abordagem é composta por(i)uma modelação multi-paradigma para re- presentar requisitos, táticas e estratégias de enganação,(ii)uma arquitetura de referência para apoiar a integração de estratégias de enganação na operação dum sistema, e(iii)um método para orientar os engenheiros na modelação de enganação. Uma ferramenta protó- tipo, um estudo de caso e uma avaliação experimental mostram resultados encorajadores para a aplicação da abordagem na prática. Finalmente, a expressividade da linguagem de modelação de enganação é avaliada por um mapeamento de cobertura de conceitos.
Palavras-chave:Segurança baseada em enganação, Engenharia de Requisitos, Arquite- turas Adaptativas de Software, Modelação Multi-Paradigma, Linguagens Específicas de Domínio.
C o n t e n t s
List of Figures xiv
List of Tables xix
Glossary xxi
Acronyms xxiii
1 Introduction 1
1.1 Context and motivation . . . 1
1.2 Problem statement and challenges . . . 3
1.3 Research questions . . . 5
1.4 Supporting technologies . . . 6
1.5 Contributions and major results . . . 8
1.6 Research methodology . . . 12
1.7 Thesis structure . . . 14
2 Deception fundamentals 17 2.1 Deception basics . . . 17
2.1.1 Defining deception . . . 18
2.1.2 Lying, deception and attempted deception . . . 19
2.2 Biases exploitation in deception . . . 20
2.2.1 Personal biases. . . 21
2.2.2 Cultural biases. . . 21
2.2.3 Organizational biases . . . 22
2.2.4 Cognitive biases . . . 22
2.3 Structured deception . . . 24
2.3.1 Key components of deception operations. . . 24
2.3.2 Deception, war and conflicts . . . 25
2.3.3 Principles and maxims of deception . . . 26
2.3.4 Maxims and rules for successful deception. . . 28
2.3.5 Methods for deceiving . . . 30
2.4 Theoretical models of deception . . . 31
2.4.1 Warfare-based models . . . 32
2.4.2 Nature-based models . . . 34
2.4.3 A system’s theory model . . . 36
2.4.4 A unified framework . . . 37
2.5 Chapter summary . . . 38
3 Technologies and models for cyber deception 39 3.1 Using deception to enhance security . . . 39
3.1.1 Fundamentals of cyber deception . . . 39
3.1.2 Goals of cyber deception . . . 41
3.1.3 Defensive deception and the cyber kill chain . . . 42
3.1.4 Advantages and limitations on the use of deception . . . 43
3.2 Security technologies based on deception. . . 45
3.2.1 Honeypots . . . 45
3.2.2 Honeytokens . . . 49
3.2.3 Decoys and low-level deception . . . 50
3.2.4 False excuses and delays . . . 52
3.2.5 Moving-target defense . . . 53
3.3 Deception models . . . 55
3.3.1 Deception taxonomies . . . 55
3.3.2 Probabilistic models . . . 60
3.3.3 Game-theory approaches . . . 60
3.3.4 Deception planning . . . 61
3.3.5 Deception architectures . . . 64
3.4 Chapter summary . . . 65
4 Multi-paradigm modeling for cyber deception 67 4.1 Introduction . . . 67
4.1.1 An overview of Deception Modeling Language (DML) . . . 68
4.1.2 Underlying principles . . . 70
4.1.3 Development methodology . . . 70
4.2 Domain analysis of deception . . . 71
4.2.1 Ontology-based deception definition . . . 71
4.2.2 Deception concepts definition . . . 72
4.3 DML design . . . 78
4.3.1 Deception Requirements Model . . . 79
4.3.2 Deception Tactic Feature Model . . . 88
4.3.3 Deception Strategy Organizational Model . . . 91
C O N T E N T S
4.4 DML semantics . . . 92
4.4.1 Logic constructions . . . 92
4.4.2 DREM semantics . . . 92
4.4.3 DTFM semantics . . . 93
4.4.4 DSOM semantics . . . 95
4.4.5 Well-formed DML Model. . . 96
4.5 DML concrete syntax . . . 97
4.6 DML in action . . . 98
4.6.1 Security goal modeling . . . 99
4.6.2 Deception requirements . . . 100
4.6.3 Deception tactics . . . 102
4.6.4 Deception tactic feature model . . . 103
4.6.5 Deception strategic organizational model . . . 104
4.7 Chapter summary . . . 106
5 A reference architecture for cyber deception 107 5.1 Introduction . . . 107
5.2 Composition models . . . 108
5.3 Underlying principles . . . 110
5.4 Deception architecture for cyber security (DACS) . . . 111
5.4.1 Deception Strategy . . . 113
5.4.2 Monitor. . . 117
5.4.3 Analysis . . . 118
5.4.4 Execution . . . 119
5.5 DACS Models . . . 120
5.5.1 Artificial Model . . . 120
5.5.2 Context Model. . . 124
5.5.3 Strategy Model . . . 125
5.5.4 Action Plan Model . . . 126
5.6 Chapter Summary . . . 128
6 Modeling deception requirements 130 6.1 Introduction . . . 130
6.2 The GoHoney process . . . 132
6.3 Deception goal modeling . . . 134
6.3.1 Define strategic objectives . . . 134
6.3.2 Identify opportunities for deceiving . . . 135
6.3.3 Set deception goals and requirements . . . 138
6.4 Tactic modeling . . . 142
6.4.1 Build or select deception operational tactics . . . 142
6.4.2 Develop deception stories . . . 147
6.4.3 Assess tactic risks . . . 148
6.5 Feature modeling . . . 151
6.5.1 Map tactics from DREM to DTFM. . . 151
6.5.2 Identify features . . . 152
6.5.3 Set dependency and exclusion constraints . . . 152
6.5.4 Set complex constraints . . . 153
6.5.5 Define custom properties. . . 153
6.5.6 Define preferences . . . 153
6.6 Strategy modeling . . . 153
6.6.1 Define strategy . . . 153
6.6.2 Define parameters and criteria . . . 154
6.6.3 Select tactics . . . 154
6.6.4 Define strategy plan . . . 154
6.7 Deception integration . . . 155
6.7.1 Select strategy . . . 155
6.7.2 Select features . . . 155
6.7.3 Map features to DACS components . . . 155
6.7.4 Generate resolution model . . . 156
6.8 Feature design pattern for DTFM . . . 156
6.8.1 Deception tactic base model . . . 157
6.8.2 Monitoring and adaptation base model. . . 159
6.9 Tool Support . . . 161
6.9.1 DREM editor. . . 162
6.9.2 DTFM editor . . . 163
6.9.3 DSOM editor. . . 165
6.10 Chapter Summary . . . 166
7 Case study 168 7.1 Introduction . . . 168
7.2 Study objectives . . . 168
7.3 e-presence description . . . 169
7.4 Select input models: the e-presence goal model . . . 170
7.5 Applying the GoHoney method . . . 176
7.5.1 Deception goal modeling . . . 176
7.5.2 Tactic modeling . . . 180
7.5.3 Feature modeling . . . 186
7.5.4 Strategy modeling . . . 191
7.5.5 Deception integration. . . 196
7.6 Evaluating the results . . . 203
7.7 Chapter Summary . . . 203
C O N T E N T S
8 An experimental evaluation 205
8.1 Introduction . . . 205
8.2 Empirical evaluation method. . . 206
8.2.1 The evaluation model. . . 207
8.2.2 The evaluation process . . . 208
8.3 GoHoney empirical evaluation . . . 210
8.3.1 Scope of the experimental study. . . 210
8.3.2 Planning . . . 211
8.3.3 Operation . . . 218
8.3.4 Analysis and interpretation . . . 219
8.3.5 Presentation and package . . . 231
8.3.6 Threats to validity . . . 232
8.4 Survey on deception technology for cyber security . . . 233
8.5 DML expressiveness evaluation . . . 237
8.5.1 Deception taxonomy mapping. . . 238
8.5.2 Metamodel relevance analysis . . . 247
8.6 Chapter summary . . . 249
9 Conclusions and future work 252 9.1 Research questions revisited . . . 252
9.2 Contributions . . . 254
9.3 Published results . . . 257
9.4 Future work . . . 258
9.4.1 Enhancements to the GoHoney suite . . . 258
9.4.2 Future research avenues . . . 259
Bibliography 261
Appendices
A GoHoney Tool: Extension Point for Building Deception Strategies 289 B Inter-item correlation analysis for empirical study 291
1.1 Closed-loop systems representation . . . 8
1.2 Design Science Research Methodology . . . 12
1.3 Thesis structure . . . 14
2.1 A typology of misperception [368] . . . 18
2.2 The relationship between lying, deception and attempted deception, adapted from [55] . . . 20
2.3 Expectation and perception [167] . . . 23
2.4 Strategic deceptive flow [31] . . . 24
2.5 Unified deception framework, adapted from [31] . . . 37
3.1 Defensive deception and the cyber kill chain [48] . . . 42
3.2 Generic model of honeypot, adapted from [191] . . . 46
3.3 Linguistic cases categories used in deception actions . . . 56
3.4 Computer systems components where deception can be integrated with [9] 57 3.5 Defensive deception taxonomy based on game-theory studies [272]. . . 58
3.6 Multi-dimension deception proposed in [151] . . . 59
4.1 Overview of the multi-paradigm modeling for cyber deception . . . 69
4.2 DREM organization . . . 79
4.3 DREM goal layer and partial KAOS goal metamodel . . . 80
4.4 Example of a goal model in KAOS (partial model). . . 81
4.5 DREM Operational layer . . . 83
4.6 DTFM metamodel . . . 89
4.7 DSOM metamodel . . . 91
4.8 DREM notation . . . 97
4.9 DTFM/DSOM notation . . . 98
4.10 AHSP: Security goals (partial model) . . . 99
4.11 AHSP: Deception requirements model . . . 100
4.12 AHSP: System Goal model and DREM integration . . . 101
L I S T O F F I G U R E S
4.13 AHSP: Example of Honey TV specification . . . 102
4.14 AHSP: Example of Voice Fabric specification. . . 103
4.15 AHSP: Example of Deception Tactic Feature Model . . . 104
4.16 AHSP: Example of Deception Strategic Organizational Model . . . 105
5.1 Deception Architecture Models . . . 109
5.2 Main components of the deception architecture for cyber security . . . 112
5.3 Logical view of the conceptual deception architecture for cyber security . . 113
5.4 Statechart showing the possible state transitions for a deception tactic . . . 116
5.5 DACS Monitor flow . . . 118
5.6 Example of delay artificial model . . . 121
5.7 Example of decoy files artificial model . . . 122
5.8 Example of services provided by decoy file tactic . . . 123
5.9 Example of honeytokens artificial model . . . 123
5.10 Example of context model (partial view) . . . 125
5.11 Example of DSOM with tactic entry point connection. . . 125
5.12 Example of DACS action plan execution . . . 126
6.1 GoHoney phases . . . 131
6.2 GoHoney main activities . . . 132
6.3 Define strategic objectives subactivities . . . 134
6.4 Identify opportunities for deceiving - subactivities . . . 135
6.5 Security goals as opportunities for deceiving. . . 136
6.6 Conflicts as opportunities for deceiving . . . 137
6.7 Define deception goals and requirements: subactivities . . . 139
6.8 Example of expected perception defined as goals . . . 141
6.9 DREM::Goal layer structure . . . 142
6.10 Build or select deception operational tactics: subactivities . . . 142
6.11 Example of reference link in DML . . . 145
6.12 Extracting goals to compute metrics. . . 146
6.13 Develop deception stories: subactivities . . . 147
6.14 Assess tactic risks: subactivities . . . 149
6.15 Build deception tactic features: subactivities . . . 151
6.16 Examples of mapping a tactic from DREM to DTFM . . . 152
6.17 Define deception strategies: subactivities . . . 154
6.18 Integrate deception strategy: subactivities . . . 155
6.19 Mapping features from DTFM to DACS. . . 156
6.20 DTFM Base model pattern . . . 157
6.21 DTFM Configuration feature pattern . . . 158
6.22 DTFM Management feature pattern . . . 159
6.23 DTFM Termination feature pattern . . . 159
6.24 DTFM Monitor feature pattern. . . 160
6.25 DTFM Analysis feature pattern . . . 161
6.26 DTFM Reconfiguration feature pattern . . . 161
6.27 GoHoney Tool: DREM editor. . . 163
6.28 GoHoney Tool: DREM tree view and analytics . . . 164
6.29 GoHoney Tool: DTFM editor . . . 164
6.30 GoHoney Tool: Feature pattern creation . . . 165
6.31 GoHoney Tool: DSOM editor. . . 165
6.32 Invoking extension points to build deception strategies . . . 166
7.1 Overview of the e-presence control system . . . 170
7.2 Student Attendance . . . 171
7.3 Attendance Confirmation. . . 171
7.4 Examples of e-presence application screen shots . . . 171
7.5 e-presence goal model, showing only the high-level goals . . . 171
7.6 Decomposition of goal Secure System (partial) . . . 172
7.7 Decomposition of goal Student Presence Computed . . . 173
7.8 Decomposition of goal Course Data Updated . . . 173
7.9 Decomposition of goal Presence Registered . . . 174
7.10 Decomposition of goal Offline Synchronization . . . 175
7.11 Decomposition of goal Online Synchronization . . . 175
7.12 DREM goal layer: strategic goals. . . 177
7.13 DREM goal layer: deception objectives . . . 178
7.14 DREM goal layer: desired perceptions . . . 178
7.15 DREM goal layer: specific goals . . . 179
7.16 DREM goal layer: deception requirements for fake files . . . 180
7.17 DREM goal layer: expressing a conflict between deception and system goals 181 7.18 DREM operational layer: deception tactics for e-presence . . . 182
7.19 DREM operational layer: tactic definition . . . 183
7.20 DREM operational layer: defining artificial elements . . . 183
7.21 DREM operational layer: defining metrics and feedback channels. . . 184
7.22 DREM operational layer: defining deception stories. . . 184
7.23 A partial threat model for the tactic Account Decoy File . . . 185
7.24 DREM operational layer: defining associated risks . . . 186
7.25 DREM: Account Decoy File . . . 187
7.26 DTFM: Account Decoy File tactic decomposition . . . 187
7.27 DTFM: Account Decoy File - Configuration . . . 188
7.28 DTFM: Account Decoy File - Services . . . 189
7.29 DTFM: Account Decoy File - Management . . . 189
7.30 DTFM: Account Decoy File - Termination . . . 190
7.31 DTFM: Account Decoy File - Monitor . . . 190
L I S T O F F I G U R E S
7.32 DTFM: Account Decoy File - Analysis . . . 190
7.33 DTFM: Account Decoy File - Reconfiguration . . . 191
7.34 DTFM: Account Decoy File - Custom property . . . 191
7.35 DTFM: Account Decoy File . . . 192
7.36 DSOM: e-presence Deception Strategies . . . 193
7.37 DSOM: All strategies . . . 193
7.38 DSOM: Minimize conflicts strategy . . . 194
7.39 DSOM: Minimize risks strategy . . . 194
7.40 DSOM: Minimize disk usage . . . 195
7.41 e-presence DSOM . . . 197
7.42 Account decoy file tactic architecture (based on DACS) . . . 198
8.1 Method Evaluation Model [250] . . . 207
8.2 Process for conducting empirical studies, adapted from [371] . . . 209
8.3 Example of activity used to measure performance-based variables . . . 214
8.4 Sequence of activities of the GoHoney survey . . . 217
8.5 Participants’ core expertise . . . 220
8.6 Participants’ expertise in deception . . . 221
8.7 Effectiveness: Professionals vs Students. . . 222
8.8 Efficiency: Professionals vs Students . . . 222
8.9 Actual Efficiency vs Perceived Ease of Use . . . 225
8.10 Actual Effectiveness vs Perceived Usefulness . . . 226
8.11 Perceived Ease of Use vs Perceived Usefulness . . . 227
8.12 Perceived Usefulness vs Intention to Use . . . 228
8.13 Perceived Ease of Use vs Intention to Use . . . 229
8.14 Summary of hypotheses tests. . . 230
8.15 Deception-technology survey: responses distribution . . . 233
8.16 Linguistic cases category used in deception actions . . . 237
8.17 Core DML concepts . . . 238
8.18 Spatial cases: example of concepts expressing locate-from, locate-to, locate-at, locate-through, direction, and orientation . . . 239
8.19 Temporal cases: example of mapping using concepts of deception story de- scription . . . 241
8.20 Participant cases: example of agent and beneficiary mapping . . . 242
8.21 Participant cases: example of instrument and object mapping . . . 242
8.22 Causality cases: example of effect, purpose, and contradiction mapping . . 244
8.23 Causality cases: example of using an intentional vulnerability to express effect 244 8.24 Quality cases: example of manner, content, value, and measure mapping . 245 8.25 Essence cases: example of whole mapping . . . 246
8.26 Speech-act cases: example of ability mapping . . . 247
8.27 Relevance analysis of metamodel elements . . . 250
8.28 DML model coverage . . . 251 9.1 Thesis core contributions . . . 254
L i s t o f T a b l e s
1.1 List of publications . . . 11
4.1 Deception tactic isolation levels . . . 84
4.2 Types of artificial elements considered in DML . . . 85
4.3 Threat likelihood assessment in DML . . . 87
4.4 Threat impact assessment in DML . . . 87
5.1 Possible states for actions in action plans . . . 127
6.1 Deception intentions and potential effects on adversaries . . . 139
7.1 Main artifacts of GoHoney method . . . 176
7.2 Summary of requirements for fake account files . . . 181
7.3 Risks associated with the tactic Account Decoy File . . . 186
7.4 Account Decoy features mapping to Deception Strategy components . . . . 198
7.5 Account Decoy features mapping to DACS monitor components . . . 200
7.6 Account Decoy features mapping to DACS analysis components . . . 200
7.7 Account Decoy features mapping to DACS Execution components . . . 202
8.1 Institutions invited to participate in the empirical study . . . 211
8.2 Dependent variables . . . 213
8.3 Items in the survey for measuring the perception-based variables, with associ- ated alternative answers . . . 215
8.4 Descriptive statistics for performance variables (all activities), N=58 . . . . 221
8.5 Descriptive statistics for perception variables, N=58 . . . 223
8.6 H1,H2, and H3 hypothesis test . . . 223
8.7 Regression between Actual Efficiency and Perceived Ease of Use . . . 224
8.8 Regression between Actual Effectiveness and Perceived Usefulness . . . 225
8.9 Regression between Perceived Ease of Use and Perceived Usefulness . . . . 226
8.10 Regression between Perceived Usefulness and Intention of Use . . . 227
8.11 Regression between Perceived Ease of Use and Intention of Use . . . 228
8.12 Spatial cases mapping. . . 239
8.13 Spatial cases mapping. . . 240
8.14 Participant cases mapping . . . 241
8.15 Causality cases mapping . . . 243
8.16 Quality cases mapping . . . 245
8.17 Essence cases mapping . . . 246
8.18 Speech-act cases mapping . . . 246
8.19 Metamodel mapping using linguistic case taxonomy . . . 247
B.1 Inter-item correlation analysis for the empirical study . . . 292
G l o s s a r y
Artificial element An element (file, code piece, message, device, etc.) that should not be in the system if no misleading techniques were used.83
Attack An assault on system security that derives from an intel- ligent threat; that is, an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system.39
Attack vector A specific path, method, or scenario that can be exploited to break into an IT system, thus compromising its security.70 Attacker An entity that attacks a system. (Compare: cracker, intruder,
hacker.); an entity that is a threat to a system.39
Cognitive bias A systematic pattern of deviation from norm or rationality in judgment.21
Countermeasure An action, device, procedure, or technique that reduces a threat, a vulnerability, or an attack by eliminating or pre- venting it, by minimizing the harm it can cause, or by dis- covering and reporting it so that corrective action can be taken.30
Deception The act of causing someone to accept as true or valid what is false or invalid.18
Dissimulation In the context of deception-based security, dissimulation means to hide something that is real.32
GoHoney A set of processes, heuristics, and patterns used to model deception requirements, tactics, and strategies for defense.
10
Intentional vulnerability An intentional controlled flaw injected into a system to en- tice attackers and consequently detect them.98
Risk An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result.69
Simulation In the deception-based security context, simulation means to show something that is false.32
Threat A potential for violation of security, which exists when there is a circumstance, capability, action, or event, that could breach security and cause harm. That is, a threat is a possible danger that might exploit a vulnerability.40
Vulnerability A flaw or weakness in a system’s design, implementation, or operation and management that could be exploited to violate the system’s security policy.6
A c r o n y m s
APT Advanced Persistent Threat1 AQL Acceleo Query Language105 AWS Amazon Web Services140
BVR Base Variability Resolution tool166 CVL Common Variability Language166
DACS Deception Architecture for Cyber Security108 DDSL Deception Domain-specific Language3
DML Deception Modeling Language68 DREM Deception Requirements Model69 DS Deception Story238
DSL Domain-specific Language70 DSM Domain-specific Modeling7
DSOM Deception Strategic Organizational Model69 DSRM Design Science Research Methodology12 DTFM Deception Tactic Feature Model69 EMF Eclipse Modeling Framework162 IM Instant Messaging48
ITU Itention to Use208
MEM Method Evaluation Model206 MTD Moving-target Defense53 NIC Network Interface Controller51
OPSEC Operational Security26
PDD Process Deliverable Diagram132 PDF Adobe Portable Document Format42 PEOU Perceived Ease of Use207
PU Perceived Usefulness208
TAM Technology Acceptance Model207
1
I n t r o d u c t i o n
Software security design does not adequately take into account the use of de- ceptive strategies as a tool for defense. Although attempts to develop methods to plan and design deceptive strategies have been made over the years, they chiefly use high-level abstractions to represent deceptive capabilities to a system. Indeed, designing deception-based defense is mostly an ad-hoc process with little practical guidance. This PhD research aims at investigating a systematic method to specify and design deception-based security. This chapter contextualizes and motivates our research problem, defines the research question and objectives pursued in this work, summarizes the major findings and the scientific validation method, and finishes depicting the scope and structure of this thesis document.
1.1 Context and motivation
Software systems play an essential role in our daily lives, from sophisticated systems, like flight control software, to single toasters and the smartphone in our hand, software is ubiquitous. Making such systems secure is one of the major challenges engineers have to deal with. Network-connected systems usually operate in a complex ecosystem under partially-trusted settings and different third-party components, which accentuate the systems’ exposure to adversaries. Additionally, advanced persistent threats (APT) are continuously increasing and getting more and more sophisticated [346, 342, 163, 76].
APT represents a wide range of sophisticated reconnaissance and information gathering tools, as well as attack tools and methods, used by skilled and well-resourced criminals to gain entry to networks and front-end servers. These are hard to detect and defend against, as evidenced by the ever-rising number of threats and successful attacks [318].
With such an increasing number of threats and incidents, companies’ capacity to in- vestigate and analyze every single security event is generally very low. A recent study1 conducted by Cisco reports that organizations are able to investigate a little more than half of the security alerts they receive daily. Of these, 28% are deemed legitimate alerts,
1The study was conducted with 2796 companies in 13 countries
and 72% are false positives; 46% of the legitimate alerts are then remediated, and 54%
are just left without remediation [76]. These findings show that the status quo of orga- nizations’ defense posture is not sufficient to undertake the current threats. Therefore, addressing the complexity and sophistication of current attacks should include not only investing in preventive and monitoring capabilities but also in mechanisms that actively engage adversaries. Such mechanisms should be able to influence the attacker’s percep- tion who hopefully will act in favor of defense.
Traditionally, defense mechanisms are conceived to passively detect and halt mali- cious behavior [161]. The primary role of these mechanisms is to deny and isolate assets from unauthorized access, or obfuscate the nature of the asset to slow down the attack- ers and reduce the probability of sensitive data leakage [10]. While traditional security mechanisms represent primary defensive posture, they have been frequently overcome by skilled adversaries who launch zero-days attacks (attacks that exploit an unknown vulnerability). When these mechanisms fail, the next layer of defense is to augment a system withdeceptive mechanismsto lead attackers astray.
Deception portrays a way to manipulate adversaries’ perception. It is considered a key component of the active defense paradigm in cyberspace [336]. The concept of active defense involves practices to detect, analyze and mitigate threats and vulnerabilities by continuously operating and improving the system’s protection capability upon multi- layer sensors [101]. Deception represents a deliberate attempt to conceal, fabricate, and manipulate factual information to create or maintain in others a belief considered false [233]. In the digital realm, deception is a well-know technique used by mal-actors to en- tice and manipulate legitimate users on their own benefit. Techniques using low-profile zero day combined with social engineering, such as a spear phishing attack, can be highly effective. Conversely, the use of deception as an element of defense has been researched since the 90’s, when early-warning and advanced security surveillance mechanisms, such as honey-like tools and techniques, were proposed [376,169,64,194]. Defense mecha- nisms based on deception are frequently used as a complementary strategy for defense.
Whereas traditional security mechanisms, such as intrusion detection systems and access controls, are conceived as first (or second) level of defense, deceptive mechanisms may be an effective way of compensating for conventional security’s inherent weaknesses [375].
To be effective, a deception mechanism must continuously estimate adversaries’ inten- tions and capabilities and apply suitable techniques of manipulation, while minimizing both the interference in the system operation and the risks of exposing real resources.
To mitigate risks and avoid system interference, many systems based on deception are designed to be completely isolated from the real systems (e.g., server honeypots [329]).
Nevertheless, these honey-systems have shown to be laborious to implement and main- tain [64]. Also, as totally “fake systems”, many tools currently exist to identify whether the system is a honey system [169,64]. In contrast, integrated deception operations pro- pose to add real systems with interacting deception-based techniques [10]. One incentive to incorporate such techniques is to produce more plausible and manageable deceptions.
1 . 2 . P R O B L E M S TAT E M E N T A N D C H A L L E N G E S
By intelligently adding fakes and decoys into a system, defenders can mislead or confuse attackers by increasing the entropy of leaked information. Since attackers do not expect systems to misinform, the surprise effect might position defense a step ahead of compro- mise attempts [10]. And even if the use of deceptive elements in a system is uncovered, the offensive still remains risky, since attackers must accurately discriminate the false from the real to make advances.
Despite advances in creating deceptive mechanisms and techniques for defense, the process of specifying and designing such solutions still remains an ad-hoc practice. In particular, as the number of deceptive mechanisms increases, strategies to coordinate these mechanisms, validate multiple deception channels, and monitor the effectiveness of integrated operations become a challenge [10]. Therefore, implications and consequences of incorporating deceptive techniques in a system should be analyzed. In recent years, the need for systematic means for specifying and designing deception operations has been spotlighted by some studies in the field of cyber deception. In 2015, Almeshekah proposes a framework to incorporate the act of deceit in the design of software [10]. This work represents an important contribution for the field, but it lacks concrete (software engineering) techniques to achieve that goal. Rowe and Rrushi discuss software engi- neering for deceptive software and systems, and present deception architectures and implementation strategies [302]. Yet again, the study lacks discussions on the use of con- crete software engineering techniques. Furthermore, design considerations for building cyber deception systems are discussed by Briskinet al. [48], who argued for the need of a deception domain-specific language (DDSL). Such DDSL, among other objectives, would serve as an unambiguous specification to guide and document the design process and the respective deception scenario implementation.
1.2 Problem statement and challenges
A central problem we have identified during the course of our research is thatsoftware security design does not adequately take into account the use of deceptive strategies as a tool for defense. Although several methods have been proposed over the years to plan and design deceptive strategies, they chiefly portray attempts to bridge military deception to cyber deception (e.g., with taxonomies of techniques) [300,303,272] or they represent high-level plans to create, deploy and execute deception-based solutions [79, 375, 9,160,336,184, 22]. Consequently,little practical guidance is provided on how to engineer deception-based defense. Specifying deception-based defense presents the following key challenges:
Challenge 1: Deception conceptualization.Computational formalisms exist to describe deception as a psychological phenomena. They formulate deception using epistemic logic to characterize the belief of agents, communication between agents, and effects of communication [353,262,308]. As strategic tool, deception is characterized by analytical
models representing the probability of successfully deceiving a target [299,298,89,183, 71]. Also, deception models are used to undertake a precise analysis of interaction in particular strategic settings, as presented in game-theory models (see [272] for a compre- hensive study). However, there is a lack of conceptual models formalizing the necessary concerns used to construct deception-based defensive mechanisms. The challenge is to build a conceptual model that balance both perspectives (psychological and strategic) with a reasonable amount of concepts that are expressive enough to model different types of deception.
Challenge 2: Deception requirements modeling.Modeling deception using current re- quirements modeling techniques, such as goal-oriented and use cases, is challenging.
Such techniques offer too general abstractions, such as agents and actors, goals, opera- tions, tasks, and resources, to deal with different concerns in a system. This prevents reasoning the model and capture specific information about a deceptive technique be- ing modeled. Consequently, most of the questions such as what artificial elements and which biases the deception operation intends to exploit can not be easily answered if deception is modeled using only the usual requirements modeling techniques. Deception specification should be supported by an adequate level of abstraction that captures the particularities of the domain, allowing to constraint the model to avoid inconsistencies.
Finally, deception should be handled as a separate concern to support reuse (e.g., certain models and operationalizations) in different contexts, trace of deception artifacts, and evolution of deception requirements without interfering on other system requirements.
Challenge 3: Deception design.Strategies exist to add deceptive capabilities to a system [161]. A program, or even an operating system, can be modified manually to incorporate deceptive elements. Deception can be also integrated by using wrappers [241] on regular code and generalized by deception control policies. Coarse-grained approaches (e.g., hon- eypots and honeynets) use virtualization technologies to simulate real systems, requiring a significant amount of configuration and tuning to make them look real [47]. Regard- less of the chosen strategy, implementing deceptive mechanisms is not a trivial task [31, 161]. From the software engineering perspective, designing and implementing decep- tive strategies adds to the developers’ system concerns. In a perfect world, a deceptive capability should be: (i)incorporated in a system without modifications on its structure and behavior, and(ii)activated and deactivated from a system without influencing on its functionality and quality. In practice, these objectives are hard to achieve since it depends on the complexity of the underlying story to be presented to an attacker. For example, if the story demands that an application deviates the normal course of processing to a honeypot, we need to modify this application to reflect this behavior. Nevertheless, mod- ularization techniques, such as component-based engineering [283] and aspect-oriented programming [205], may alleviate the burden of incorporating deceptive capabilities in a system.
1 . 3 . R E S E A R C H Q U E S T I O N S
Challenge 4: Effective deception mechanisms.Skilled attackers are not easy to mislead.
To increase the chances of deceiving them, a deception story should be plausible and entic- ing, reflecting how realistic it looks like. Generally, the most convincing cover stories are based on what the opponent already believes and wants to believe [160]. If the opponent is suspicious of the artifices, the effectiveness of the deception decreases. An enticing fake element acts like a magnet for attackers. Producing plausible and enticing decep- tions is challenging because plausibility and enticibility are subjective properties that can not be easily evaluated by deterministic methods [79], and because what is plausible and enticing in a certain moment may not be so later in time. Therefore, it is important to manage the deception life cycle, from initiation to termination. More specific, a de- ceptive mechanism can be statically (always available) or dynamically (available under certain conditions) activated; it must be monitored to identify attacker engagement and determine conditions to which the mechanism should adapt itself to keep the cover story realistic and enticing.
Challenge 5: Technical expertise.The use of deceptive techniques for defense is not a component of regular security curricula; this is evidenced by the lack of in-depth related content in classic security books (e.g., [334, 16]) and certification programs (e.g., [176, 82]). Therefore it is expected that deficiencies arise due to lack of engineers’ experience in building deceptive solutions. To alleviate such deficiencies, engineers should be guided by a method, i.e., a set of detailed and consistent activities and heuristics that facilitate the process of designing deception strategies. However, it is difficult to build an expressive method that soften the learning curve while increasing the chances of adopting it [93].
Moreover, such method should be able to point opportunities for deceiving an opponent based on system artefacts. In this sense, it is challenging to identify opportunities in a large spectrum of features and resources a system may contain.
1.3 Research questions
The challenges discussed show the need for systematic means to support modeling decep- tion in the early stages of the software development process. Therefore, this PhD research aims to contribute with an approach to model deception by addressing the following main research question:
How to systematically specify and design deception-based security?
To tackle the problem and corresponding challenges we identified, we subdivide the main research questions into more manageable sub research questions:
SRQ1: How to characterize strategic deception for software security?
SRQ2: How to effectively support the specification of deception requirements?
SRQ3: How can deceptive software be architecturally designed?
SRQ4: How to guide engineers in the modeling of deception-based strategies?
To compose a systematic method for specifying and design deception-based security, we need first to provide a precise account (Challenge 1) for deception considering it as both mental state and strategic tool for cyber defense. This challenge is addressed by the research question SRQ1. An adequate method to specify deception requirements must consider the appropriate level of abstraction (Challenge 2) to model concerns of deception domain. Research question SRQ2 addresses this challenge. To alleviate the burden of designing multi-deceptive strategies (Challenge 3) for a system, there is a need of an architectural model that promotes reuse and manage deceptive mechanisms life cycle. Also, to maintain the effectiveness of a cover story (Challenge 4), this architectural model must provide support for deception mechanisms to adapt. These two challenges are addressed by the research question SRQ3.
Finally, to use systematically a method and mitigate the eventual lack of expertise in deception (Challenge 5), engineers should be guided by instructions, heuristics, and patterns that help them identify opportunities for deceiving, structure the models to express different views of deception (e.g., goal view, operationalization view, and strategy view), and integrate these models with existing models, such as the system requirements model and a threat model. This challenge is addressed by our research question SRQ4.
1.4 Supporting technologies
To establish a systematic and scientific perspective for deception-based security engi- neering, we need to clarify which are the major technologies supporting the design and development of our approach. Our work is based on four main areas: Goal-oriented security requirements engineering, domain-specific modeling, cyber deception, and self- adaptive systems. We briefly describe each topic next.
Goal-oriented security requirements engineering.Security requirements engineering is an area in software engineering devoted to identify and analyze security early, dur- ing the requirements phase [19].Security Requirements are defined as constraints on the functions of the system, and these constraints operationalize one or more security goals.
Therefore, security requirements are specified and then translated to a set of mechanisms that will be part of the system to-be. Agent and goal-oriented security requirements ap- proaches consider security concerns over social interactions among agents and goals that should be satisfied in the system-to-be. Threats jeopardize a goal from being satisfied.
They are generally expressed as anti-goals, i.e., the goal under an attacker’s perspective.
For example, in KAOS, threats are modeled as obstacles that are refined down to specific actions that will exploit avulnerabilityin the system [356]. Security requirements are specified as countermeasures to mitigate threat’s consequences.
1 . 4 . S U P P O R T I N G T E C H N O L O G I E S
Domain-specific modeling.Throughout the history of software development, engineers have always sought to improve productivity by improving abstraction. Domain-specific modeling (DSM) aims at raising the level of abstraction beyond current modeling lan- guages by specifying the solution directly using problem domain concepts [202]. DSM is a component of model-driven development, in which models are used for designing systems, understanding them better, specifying required functionality, and creating docu- mentation. Domain-specific modeling is realized by domain-specific languages that apply the concepts of a particular problem domain. Similar to general-purpose languages, mod- eling languages consist of syntax and semantics. Syntax is further distinguished between abstract and concrete syntax. Abstract syntax denotes the structure and grammatical rules of a language. It is normally specified in a metamodel describing concepts (ideally from the problem domain) and their relationships. On the other hand, concrete syntax deals with the representational form of the language. Semantics define the meaning of the concepts expressed in the language. In a DSM, semantics come to some extent from the problem domain. DSM can be used in various areas of software engineering, such as requirements engineering, software architecture, developer utilities, implementation, product line engineering and business analysis. In particular, DSM approaches for re- quirements engineering aim at supporting the description of precise, check-able, and traceable requirements [360]. In contrast to other software engineering areas, DSM for requirements engineering does not focus on automatic code generation.
Cyber deception. Deception represents a deliberate misrepresentation of reality done to gain a competitive advantage over adversaries [91]. Strategic deception has a strong background in the military area with several notable cases in the literature (see [297] for a selection of cases). In cyber space, deception has been employed as a means to learn about tactics used by skilled attackers but also to protect the system by influencing the thinking of the target. Cyber deception is an emergent topic in computer security [161].
Studies related to cyber deception can be classified into two major categories: deception technologies and implementations, and deception models, methods, and processes. The first are studies related to specific solutions involving a particular technology or threat model (e.g., honeypots [329], honeytokens [26,330], and decoy files [376,43]), and the second are devoted to theoretical aspects of deception and engineering disciplines to build deception strategies (e.g., taxonomies [300,303,151] and process models [29,375, 9]). Deception models, methods, and processes is the central topic of our work, offering an engineering perspective for developing defensive deception-based solutions.
Self-adaptive systems.Self-adaptive software systems are characterized for having the capability of modifying their behavior in response to their perception of the context, their requirements, and their state [213]. The termself represents the whole body of the soft- ware, mostly implemented in several layers, while the context encompasses everything in the operating environment that affects the system’s properties and its behavior, such
as end-user input, external hardware devices and sensors, or program instrumentation [268]. The key point in self-adaptive software is that its life-cycle should not be inter- rupted after its development and initial set up. This cycle should be continuous after deployment in order to evaluate the system and respond to changes at all times. In this sense, self-adaptive systems are realized as closed-loop systems with a feedback loop[17].
As illustrated in Figure1.1, the closed-loop system consists of mechanisms that monitor the system, reflect on observations for problems, and control the system to maintain it within acceptable bounds of behavior. This kind of system is known as feedback control systems in control theory [317]. In component-based systems, dynamic architectures are
Controller Process
Feedback
input output
sensoring
Figure 1.1: Closed-loop systems representation
characterized by modifying the composition of the interacting components during the course of their execution [7]. Thus, reconfiguring a system implies to change some of its characteristics (functional or non-functional) for a certain purpose. Reconfiguration mechanisms vary on the level of automation. While fully automated reconfiguration may require sophisticated mechanisms to make decisions by themselves (e.g., based on situation-action [65], goal-based approaches [204], or utility functions [363,203]), man- ual interventions relies on human judgment and consequent action to move the system from one state to another.
Other technologies. Other technologies commonly known by requirements engineers, such as KAOS [357] and the Unified Modeling Language (UML) [230]), and security engi- neers, such as threat modeling [323] and attack trees [235] are also used in our approach.
1.5 Contributions and major results
Our major result relies on a comprehensive approach that goes from problem under- standing, conceptualization, and structuring to tool prototyping and empirical evalua- tion. While the approach can be used for offensive deception, our focus is on defensive deception, that is, using deceptive mechanisms to deflect attacks. We overview now the eight building blocks that compose the major achievements of this PhD thesis.
1 . 5 . C O N T R I B U T I O N S A N D M A J O R R E S U LT S
Core ontology of cyber deception. We propose a core ontology of cyber deception to rep- resent concepts involving both psychological and strategic deception. The term deception can be thought in two perspectives: a mental state and a strategic tool. As a mental state, a deceiver deceives by manipulating the perception a deceivee owns about the reality. As a strategic tool, the term deception means operations based on deception, i.e., the use of stratagems to take some advance over an adversary. We formalize these perspectives as part of the work needed to address research question 1 (SRQ1). Chapter4discusses this result.
Multi-paradigm modeling approach for deception requirements We design the De- ception Modeling Language (DML) and integrate it with existing modeling approaches, providing a multi-paradigm approach for modeling deceptive mechanisms. DML is a domain-specific requirements modeling language focused on the operationalization of deception tactics and strategies composition. DML works in tandem with the KAOS goal- oriented model, threat/attack models, and UML models, to express static and dynamic aspects of deception tactics. It promotes the separation of deception concerns from regu- lar security concerns by allowing the specification of stratagems using domain concepts (e.g., simulation, dissimulation, artificial elements, biases, and intentional vulnerabili- ties). Also, DML offers traceability support from the deception requirements phase down to the reference architecture components. DML can express three core models: Deception Requirements Model (DREM), Deception Tactic Feature Model (DTFM), and Deception Organizational Model (DSOM). These models represent different views, each organizing specific levels of information. DREM captures the requirements and alternative forms of operationalizing deception using the concept of tactic. Each tactic is decomposed into features in a DTFM, bridging the gap between requirements and the implementation. Fi- nally, DSOM organizes the tactics into different strategies according to a set of criteria. A strategy containing a set of deception tactics can be enacted to add deceptive capabilities to a system. DML contributes to address research question 2 (SRQ2). Chapter4discusses this result.
Conceptual Architecture. We propose the Deception Architecture for Cyber Security (DACS), a reference architecture that describes the basic components of deceptive sys- tems with self-adaptive capabilities to maintain plausible stories. Our architecture is model-driven and relies on [email protected] [35] to monitor, analyze, and reconfigure tactics that add deceptive capabilities into a system. DACS is structured to support the management of deceptive tactics and artificial elements. It has two main goals: (i)pro- mote the reuse and(ii)alleviates potential interferences deception can cause in the sys- tem operations. To promote reuse, DACS employs either component-based technology and/or aspect-oriented techniques to manage artificial elements. To alleviate potential interferences deception can cause in the system operations DACS concentrates the com- munication between a tactic and a system component through the use of proxies. DACS
contributes to address research question 3 (SRQ3). Chapter5discusses this result.
GoHoney method.We propose theGoHoneymethod to guide the DML modeling activity.
The GoHoney method encompasses a process, a set of heuristics, and a design feature pattern. The process delineates the necessary steps to (i)set the objectives of inserting deceptive mechanisms in a system,(ii)identify opportunities for the use of deception con- sidering general, domain, and application-specific characteristics of a system,(iii)build strategies for deceiving, and(iv)map tactics to DACS components. Heuristics conduct to potential solutions for a given problem. In our case, they offer suggestions to engi- neers during the process of deception modeling. The feature design pattern is an abstract pattern that helps decomposing deception tactics into common features that are further refined into more specific characteristics. The GoHoney method contributes to address research question 4 (SRQ4). Chapter6discusses this result.
Tool prototype.We propose the GoHoney tool prototype to support the creation of DML models (DREM, DTFM, DSOM), as well as goal models based on KAOS, and threat/attack models. Thus, the GoHoney tool provides an integrated environment to model distinct as- pects of deception. This tool prototype contributes to address research question 4 (SRQ4).
Chapter6discusses this result.
Empirical studies.We perform two empirical studies: a case study and an experimental study. The case study involved the e-presence system, which was designed to control the presence of student in events like classes, exams, and seminars. It uses the student card to collect the presence using a mobile reader and the Lectures’ smartphone. In the experimental study, we applied the Method Evaluation Model (MEM) to predict the like- lihood of the GoHoney method being accepted in practice. This was done by evaluating the variables actual efficacy (efficiency and effectiveness), perceived efficacy (ease of use and usefulness), and intention to use the GoHoney method.
The experimental study was conducted among technology industry practitioners and students enrolled in computer-related courses. In addition, we conduct an exploratory study to understand how practitioners and students perceive deception-based technolo- gies as a mean of enhance the security of software systems. These empirical studies contribute to address all research questions(SRQ1 to SR4). Chapters 7 and8 discuss these results.
Expressiveness evaluation.We perform the expressiveness evaluation of DML by mea- suring the correlation of terms expressed in the taxonomy of deception based on linguistic cases with concepts available in DML. This evaluation contributes to address research questions 2, 3, and 4 (SRQ2, SRQ3, SRQ4). Chapter8discusses this result.
Scientific publications.Throughout the development of this thesis, the outcomes of the
1 . 5 . C O N T R I B U T I O N S A N D M A J O R R E S U LT S
research work has been published in international conferences and in one journal, as summarized in Table1.1. Each venue is classified according to impact factor2(IF) or the CORE-ERA ranking3.
Some of the results of this PhD research are still being prepared for publication, in particular, a deception tactics catalog and another on adaptive defense using deception.
Table 1.1: List of publications
Publication Venue
Ranking (J) Multi-paradigm deception modeling for cyber defense[98]
Journal of Systems and Software (JSS) 141, 2018 IF: 2.450
(DOI: 10.1016/j.jss.2018.03.031)
Contribution: The DML multi-paradigm modeling approach allows modeling deceptive tactics and strategies. DML integrates existing modeling methods (e.g., goal-oriented modeling, threat modeling, and feature modeling).
(C) A SPL Framework for Adaptive Deception-based Defense[95]
51st Hawaii Int. Conf. on System Sciences (HICSS), 2018 CORE-A (DOI: 10.24251/hicss.2018.691)
Contribution: A framework based on software product lines and aspect-oriented techniques to generate adaptive deception-based defense strategies supported by a reference architecture for cyber deception.
(C) Visual Modeling of Cyber Deception[97]
Symp. on Visual Languages and Human-Centric Comp. (VL/HCC), 2018 CORE-B (DOI: 10.1109/VLHCC.2018.8506515)
Contribution: A visual language for deception modeling, offering three comple- mentary views of deception: requirements model, deception tactics feature model, and deception strategy organizational model.
(C) Deception planning models for cyber security[99]
17th Int. Conf. on Comp. Science and Its Applications (ICSSA), 2017 CORE-C (DOI: 10.1109/ICCSA.2017.8000014)
Contribution: An exploratory study aiming at identifying the scope of decep- tion planning models, which tools have been used to plan deception, and how deception planning has been integrated to software development activities.
(C) Goal-driven deception tactics design[116]
27th Int. Symp. on Software Reliability Engineering (ISSRE), 2016 CORE-A (DOI: 10.1109/ISSRE.2016.44)
Contribution: A systematic goal-driven approach to include deception tactics early in the software development process. The process integrates system model- ing (producing a goal model of the application domain), security modeling (pro- ducing a threat model specifying the typical security concerns from the attacker perspective), and deception modeling (producing models expressing deception tactics, strategies, and stories).
(C) Designing adaptive deception strategies[96]
Int. Conf. on Sof. Quality, Reliability and Sec. Companion (QRS-C), 2016 CORE-B (DOI: 10.1109/QRS-C.2016.15)
Contribution: A process model to specify coordinated deception tactics as part of an adaptive life cycle that monitors and modifies deception strategies according to environment changes and attackers interactions.
(C)onferences, (J)ournal
2https://www.journals.elsevier.com/journal-of-systems-and-software 3http://portal.core.edu.au/conf-ranks/
1.6 Research methodology
This work aims at performing fundamental and applied research in the area of deception- based defense requirements specification and design. To achieve this objective, we fol- low the design science research methodology (DSRM), which aims at producing and presenting design science research in information systems [274]. The design science is prescriptive (or normative), i.e., it attempts to improve performance by a rigorous process to design artifacts (constructs, models, methods, and instantiations) to solve observed problems [232]. Figure1.2illustrates the six activities composing DSRM (adapted from [274]).
Problem identification and motivation 1
Solution objectives definition 2
Design and development 3
Demonstration 4
Evaluation 5
Communication 6
Figure 1.2: Design Science Research Methodology
InProblem identification and motivation, the research problem is identified and the value of a solution is justified. This involves understanding the relevance of the problem and the weaknesses of the existing solutions. Thus, this activity is grounded by existing theoretical body of knowledge on the topic of interest. InSolution objectives definition, we state the general objectives and specific criteria that the solution should meet. The Design and developmentactivity outlines the creation of the solution artifacts (e.g., con- structs, models, methods, or instantiations). Demonstrationaims at proving, by solving one or more instances of the problem, that the artifact works. Evaluationobserves and measures the results, by comparing them with the objectives. Finally, theCommunication activity involves communicating the problem, its solution, and the utility, novelty, and effectiveness of the solution to the community (e.g. researchers, industry partners, and other relevant audiences).
Notice that this process is iterative, where activities, such as Evaluation and Com- munication, often result in revising the artifact’s objectives and design. For a better
1 . 6 . R E S E A R C H M E T H O D O L O G Y
understanding how the research method has been applied in our research, we identify the work performed within each activity.
1. Problem identification and motivation: we conducted an extensive literature re- view to map and categorize the existing related studies. This led us to recognize that studies considering deception-based security are classified into two main areas:
(i)technology and implementation, and(ii)models, methods and processes. This thesis is based on a growing body of knowledge on deception theory, cyber decep- tion, and security requirements modeling and design. As we previously mentioned, scientific research projects lack practices of engineering for specifying and design deception strategies. An engineering perspective for cyber deception allows identi- fying implications and consequences of incorporating such type of solutions early in the system development life cycle. Consequently, more predictable and reusable solutions can be constructed.
2. Solution objectives definition: in this activity we defined the research questions (Section1.3) that drove the design and development of our proposed solution: a systematic approach to specify and design cyber deception strategies.
3. Design and development: the problem solution is framed by the set of proposed solutions associated with each research question, and consists of three components:
(i)models,(ii)method, and(iii)tools. The combination of these three components gives the appropriate answer to the research questions.
4. Demonstration: we developed illustrative examples to demonstrate the feasibility of the models, method and the tool proposed in this research.
5. Evaluation: we employed a case study involving a mobile system that controls the students’ presence, an experimental study involving practitioners and students en- rolled in computer-related courses. The objective of the case study was to show the feasibility of GoHoney method to identify opportunities for deceiving, to model tactics and strategies, and to map tactics to DACS components. The experimental study was focused to predict the likelihood of the GoHoney method being accepted in practice. Moreover, we applied a survey to collect impressions on deception tech- nologies. Also, we evaluated the expressiveness of DML for specifying deception requirements by correlating its features with a well-know taxonomy of deception.
6. Communication: the outcomes of this research were disseminated through scien- tific publications in the form of papers in international conferences and articles in journals indexed by the main scientific databases, such as ACM, IEEE, and Springer (see Section1.5).
1.7 Thesis structure
The structure of this thesis document, illustrated in Fig.1.3, shows, apart from the typ- ical introductory and concluding chapters, three major sets of chapters: two chapters discussing the current theoretical body of knowledge on deception and cyber deception, and five contributory chapters, of which two target evaluation of the results. In particular, Chapters 4to 6address the design, development, and demonstration of our systematic approach for deception modeling, and Chapters 7and 8tackle the validation of this PhD research. Each of these chapters is described next.
Chapter 1 Introduction
Chapter 4
A multi-paradigm modeling for cyber deception
Chapter 5
A reference architecture for cyber deception
Chapter 6 Modeling deception requirements
Chapter 7 Case study
Chapter 9 Conclusions and future work
Chapter 2 Deception fundamentals
Chapter 3
Technologies and models for cyber deception
Chapter 8 An experimental evaluation
Thesis Structure
Theoretical body of knowledge
Contributions
Validation
Figure 1.3: Thesis structure
Chapter1. Introduction.This chapter discusses the context and motivations of this PhD research, identifies the problem and the associated challenges this research aims to tackle, defines the research question, describe the core underlying technologies used in the de- velopment of this research, summarizes our major results, and overviews the adopted research methodology.
Chapter 2. Deception fundamentals. This chapter presents fundamental concepts of deception as a psychological phenomenon, and identifies the relationship between de- ception, lying, and attempted deception. It exploits potential human biases that enable deception and introduces the idea of structured deception, highlighting its key compo- nents, methods for deceiving, and its importance in the military field. Finally, it describes the main conceptual models and theories of deception, including the principles and max- ims that guide the development of deception operations.
