Trust engineering framework for software services

UNIVERSITY OF MALAGA Trust Engineering Framework for Software Services by Francisco Moyano Lara Computer Science and Languages Department University of Malaga submitted in fulfillment of the requirements for the Degree of Doctor in Computer Science Advisors M. Carmen Fernández Gago Senior Research Fellow at University of Malaga Fco. Javier López Muñoz Full Professor at University of Malaga June 2015 AUTOR: Francisco Moyano Lara http://orcid.org/0000-0002-0148-9624 EDITA: Publicaciones y Divulgación Científica. Universidad de Málaga Esta obra está bajo una licencia de Creative Commons Reconocimiento-NoComercialSinObraDerivada 4.0 Internacional: Cualquier parte de esta obra se puede reproducir sin autorización pero con el reconocimiento y atribución de los autores. No se puede hacer uso comercial de la obra y no se puede alterar, transformar o hacer obras derivadas. http://creativecommons.org/licenses/by-nc-nd/4.0/legalcode Esta Tesis Doctoral está depositada en el Repositorio Institucional de la Universidad de Málaga (RIUMA): riuma.uma.es A Noni y mis padres, las personas más importantes en mi vida. ii Acknowledgements First of all, I would like to express my deepest gratitude to my supervisors, Carmen Fernandez and Javier Lopez. Both of them have made the process of developing my thesis smooth and rewarding. And more important, over time they have become more than supervisors and colleagues; they have become really good friends, something I feel proud of because they are excellent persons. Along the development of my thesis, I have met and worked with lots of people at NICS Lab. There are not enough kind words in the English vocabulary that I can devote to these people. Guys, you are awesome and my experience working with you has been legen... wait for it! I must start expressing my gratitude to my office buddies and Pokemon friends, Ana and David, with whom I have shared so many epic moments. I still recall my first work in the group together with Pablo, a fantastic person who initiated me in the research world, concretely with RFID readers and tags (which by the way may have inclined me towards becoming the tags master...). My next Pokemon master was Rodrigo, an authentic geek (in the best sense of the word) with whom I share the passion for videogames and sushi. He made a fantastic job at co-supervising my master thesis. The rest of NICS guys are equally awesome, including those not working here any longer. I can only hold good thoughts and share kind words about every of them: Gerardo, Noelia, Rubén, Lorena, Jesús, Isaac, Cristina, Dani, Miguel, Saúl, Jose, Edu, Pepe, Montes, Onieva... All of them have contributed something to me, and have made me feel really appreciated. Thank you! There are three people that have been essential during my thesis, but much more importantly, over my life: my parents, Ana and Francis, and my girlfriend Noni. Regarding my parents, I can only say that they are always there for me and that they are the best parents in the world, and that without them, I would not have come this far. iii As for Noni, what can I say? She is one of the best persons I have ever known and our love has always inspired and encouraged me to go ahead and become a better person. I am always thrilled when I think of our future together. The good thing of having a small yet loving family is that I can share even more love with each of its members: my grandparents, Conchi, Paco, Chus and Miguel (who, in spite of not being physically here any longer, I know that he always cares for me); my aunts and uncles, Suli, Miguel, Chari and Sergio; my cousins Ali, Sergio, Dani and Miguelito; my mother-in-law Manoli; and my brother-in-law Juanma. I have been so lucky to count on all of them... Some long-life friends must be listed here of course. Ernesto, who was my first best friend and who taught me how to ride a bike; Raul, with whom I learned how to dance Latin music; Oliver, the best musician I will ever know; Jose Angel (brown), with whom I share the most exciting discussions about religion; Jose Angel (blonde), who helped me discover how Cadiz and Jerez can bring good friends together even more; Santi, because deep friendship links can never be broken, even when distance might seem an unavoidable obstacle. I would also like to devote some thankful words to my colleagues during the master’s degree, especially those in the ISP group, who have become close friends over time and with whom I have shared so many fun and geek moments. During the development of NESSoS, the project that helped shape my thesis, I have met clever and nice people with whom I had the opportunity to work. Kristian, a great German guy who will always have a place in Malaga; Jorge Cuellar, who provided me with useful insights that helped me improve my research; Benoit, who gave me a warm welcome to his fantastic research lab during my ph.D. stay in Rennes; and JeanEmile, who worked closely with me during my stay and helped me every time I found a stumbling block. I am also grateful to some institutions and projects for their funding and support. This thesis has been primarily funded by the Spanish Ministry of Education under the FPU fellowship. Special thanks go to the NESSoS (FP7 256890) project, because, as mentioned earlier, it has helped me pave the path of my thesis, it has given me the opportunity to collaborate with other institutions and high quality researchers, as well as to receive feedback for improving the quality of my research and make good friends. iv Agradecimientos Antes de nada, quisiera expresar mi más profundo agradecimiento a mis directores, Carmen Fernández y Javier López. Ambos han convertido el desarrollo de la tesis en un proceso agradable y gratificante. Y lo que es más importante, a lo largo del tiempo se han convertido en más que directores y compañeros; se han convertido en buenos amigos, lo cual me llena de orgullo porque son unas personas fantásticas. A lo largo del desarrollo de mi tesis, he conocido y trabajado con muchas personas en NICS Lab. No hay suficientes palabras amables que pueda dedicar a estas personas. Sois todos geniales, y mi experienca trabajando con vosotros ha sido legen... ¡espera un momento! Debo empezar por mostrar mi gratitud a mis compis de oficina y amigos Pokemon, Ana y David, con los cuales he vivido momentos realmente épicos. Aún recuerdo mi primer trabajo en el grupo de la mano de Pablo, una persona fantástica que me inició en el mundo de la investigación, concretamente con etiquetas y lectores RFID (lo que pensándolo bien puede que haya llevado a convertirme en el maestro de las etiquetas...). Mi siguiente maestro Pokemon fue Rodrigo, un verdadero friki (en el mejor sentido de la palabra), con quién comparto la pasión por los videojuegos y el sushi, y quien hizo un trabajo sobresaliente al co-dirigir mi proyecto final de carrera. El resto de los miembros de NICS son igualmente alucinantes, incluyendo los que ya no trabajan aquí. Sólo puedo compartir buenas palabras sobre cada uno de ellos: Gerardo, Noelia, Rubén, Lorena, Jesús, Isaac, Cristina, Dani, Miguel, Saúl, Jose, Edu, Pepe, Montes, Onieva... Todos ellos me han aportado algo, y me han hecho sentir realmente querido en el grupo. ¡Gracias! Hay tres personas que han sido imprescindibles durante esta tesis, pero mucho más importante, a lo largo de mi vida: mis padres Ana y Francis, y mi novia Noni. En cuanto a mis padres, sólo puedo decir que siempre están ahí para mí y que son los v mejores padres del mundo, y que sin ellos, no habría llegado tan lejos. Y de Noni, ¿qué puedo decir? Es una de las mejores personas que he conocido y nuestro amor siempre me ha inspirado y animado a seguir adelante y a convertirme en mejor persona. Me llena de emoción y alegría pensar en nuestro futuro juntos. Lo bueno de tener una familia pequeña es que puedo compartir incluso más amor con cada uno de sus miembros: mis abuelos, Conchi, Paco, Chus y Miguel (quién, a pesar de no estar físicamente, sé que siempre está cuidando de mí); mis tías y tíos, Suli, Miguel, Chari y Sergio; mis primos Ali, Sergio, Dani y Miguelito; la familia de Noni, Manoli y Juanma. He sido tan afortunado de poder contar con todos ellos... Mis amigos de toda la vida tienen un lugar aquí por supuesto. Ernesto, que fue mi primer mejor amigo y quién me enseñó a montar en bici; Raúl, de quien aprendí a bailar música latina; Óliver, el mejor músico que jamás conoceré; José Ángel (moreno), con quien he compartido las discusiones más interesantes sobre religión; José Ángel (rubio), con quién he descubierto que Cádiz y Jerez pueden unir a los buenos amigos incluso más; Santi, porque la auténtica amistad nunca pueden romperse, incluso cuando la distancia pueda parecer un obstáculo insalvable. También me gustaría dedicar unas palabras de agradecimiento a mis compañeros durante la carrera, especialmente a aquéllos del grupo ISP, quienes se han convertido en buenos amigos a lo largo del tiempo y con quienes he compartido tantos momentos divertidos y frikis. Durante el desarrollo de NESSoS, el proyecto que ha ayudado a dar forma a mi tesis, he conocido gente amable e inteligente con quién he tenido la oportunidad de trabajar. Kristian, un genial chico alemán que siempre tendrá un lugar en Málaga; Jorge Cuéllar, quién me ha ofrecido interesantes reflexiones para mejorar mi investigación; Benoit, que me acogió amablemente en su genial grupo de investigación durante mi estancia en Rennes; y Jean-Emile, con quién trabajé estrechamente durante mi estancia y que me ayudó cada vez que me encontraba una piedra en el camino. Esta tesis ha sido principalmente financiada por el Ministerio de Educación a través de la beca FPU. Debo agradecer especialmente al proyecto NESSoS (FP7 256890) porque ha pavimentado el camino de mi tesis, me ha dado la oportunidad de colaborar con otras instituciones e investigadores de alto prestigio, así como de recibir opiniones para mejorar mi investigación y hacer buenos amigos. vi Contents List of Figures xi List of Tables xv Listings xviii Acronyms xix 1 Introduction 1 1.1 Research Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.1 Secure System Engineering . . . . . . . . . . . . . . . . . . . . . 2 1.1.2 Trust Management . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.3 Trust, Security, Risk and Trustworthiness . . . . . . . . . . . . . 5 1.2 Goals and Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2.1 Thesis Contributions . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2.2 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3 Publications and Funding . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Understanding Trust: A Systematic Analysis 17 2.1 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.1 Trust Taxonomies . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.2 Trust in the Computing Domain . . . . . . . . . . . . . . . . . . 21 2.1.3 Trust in the Software Development Life Cycle . . . . . . . . . . . 25 2.2 Trust Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2.1 Trust Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2.2 Trust Models: Definition and Classification . . . . . . . . . . . . 34 2.2.3 Trust Models Concepts . . . . . . . . . . . . . . . . . . . . . . . . 36 vii LIST OF FIGURES xiv List of Tables 2.1 Trust Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.2 Common Features Comparison . . . . . . . . . . . . . . . . . . . . . . . 43 2.3 Decision Models Comparison . . . . . . . . . . . . . . . . . . . . . . . . 43 2.4 Evaluation Models Comparison . . . . . . . . . . . . . . . . . . . . . . . 44 2.5 Evaluation Models Comparison (II) . . . . . . . . . . . . . . . . . . . . . 44 3.1 Stakeholder Trust Template . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2 Cloud Provider Trust Template . . . . . . . . . . . . . . . . . . . . . . . 55 3.3 CSA Cloud Threats and their Evaluation . . . . . . . . . . . . . . . . . 56 3.4 Trust Interval Summations . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.5 Trust Factors Quantification for Microsoft . . . . . . . . . . . . . . . . . 62 3.6 Trust Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.7 Trust Intervals for Cloud Providers . . . . . . . . . . . . . . . . . . . . . 63 3.8 Permissions on Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.9 Relationships between Resources . . . . . . . . . . . . . . . . . . . . . . 69 3.10 Predicates for ASP SI* Formalization . . . . . . . . . . . . . . . . . . . . 70 3.11 Predicates for the Asset Model . . . . . . . . . . . . . . . . . . . . . . . 71 3.12 Axioms for Identifying Indirect Assets . . . . . . . . . . . . . . . . . . . 72 3.13 Axioms for Identifying Insider Threats . . . . . . . . . . . . . . . . . . . 76 3.14 ASP Formalization for SI* Model . . . . . . . . . . . . . . . . . . . . . . 79 3.15 ASP Rules for SI* Model Instantiation . . . . . . . . . . . . . . . . . . . 80 3.16 OCL Expressions that support Trust-based Security Reasoning and Consistency Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.17 Use Case Diagram Extensions . . . . . . . . . . . . . . . . . . . . . . . . 102 3.18 Class Diagram Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 103 xv LIST OF TABLES 3.19 Tagged Values for Class Diagrams . . . . . . . . . . . . . . . . . . . . . 104 3.20 Deployment Diagram Extensions . . . . . . . . . . . . . . . . . . . . . . 105 4.1 Entity Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.2 Trust Relationship Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.3 Reputation Statement Table . . . . . . . . . . . . . . . . . . . . . . . . . 127 4.4 Beliefs Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 4.5 Entity Table Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 4.6 Trust Relationship Table Example . . . . . . . . . . . . . . . . . . . . . 138 4.7 Reputation Statement Table Example . . . . . . . . . . . . . . . . . . . 138 5.1 Trust Factors for Marsh’s Model . . . . . . . . . . . . . . . . . . . . . . 170 5.2 Amount of Framework-related Activities . . . . . . . . . . . . . . . . . . 180 xvi Listings 3.1 IDHE001. List all biddable domains that are not a human entity . . . . 89 3.2 CCTV001. Check that all dependencies with a trust relationship have a dependency to a TrustValue . . . . . . . . . . . . . . . . . . . . . . . . . 89 3.3 CCL001. List all sources of claims that are not a Human Entity . . . . . 97 4.1 Engine Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 4.2 Excerpt of EngineManager . . . . . . . . . . . . . . . . . . . . . . . . . . 129 4.3 Creating a Bounded Claim . . . . . . . . . . . . . . . . . . . . . . . . . . 133 4.4 Binding Claim Type and Event . . . . . . . . . . . . . . . . . . . . . . . 133 4.5 Implementing Trust and Reputation Engines . . . . . . . . . . . . . . . . 134 4.6 Configuring Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 4.7 API Call for Sending the Event . . . . . . . . . . . . . . . . . . . . . . . 135 4.8 Changing a Belief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 4.9 Framework Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 5.1 Definition of Console in Kevoree . . . . . . . . . . . . . . . . . . . . . . 146 5.2 Querying the model@runtime layer . . . . . . . . . . . . . . . . . . . . . 147 5.3 TrustEntity Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 5.4 Trust Entities Initialization . . . . . . . . . . . . . . . . . . . . . . . . . 154 5.5 Adding Trust Relationships with the EMF API . . . . . . . . . . . . . . 155 5.6 TrustModel Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 5.7 CentralReputableEntity Component . . . . . . . . . . . . . . . . . . . . 157 5.8 ReputationManager Component . . . . . . . . . . . . . . . . . . . . . . . 158 5.9 DistReputableEntity Component and Reputation Engine Initialization . 159 5.10 ReputationEngine Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 5.11 Reconfiguration Rules Processing . . . . . . . . . . . . . . . . . . . . . . 163 5.12 ScriptEngine: Remove Component . . . . . . . . . . . . . . . . . . . . . 164 xvii LISTINGS 5.13 Console in the Ebay Reputation Model . . . . . . . . . . . . . . . . . . . 166 5.14 Ebay Reputation Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 5.15 Console in Marsh Trust Model . . . . . . . . . . . . . . . . . . . . . . . 170 5.16 Trust Engine for Marsh’s Model . . . . . . . . . . . . . . . . . . . . . . . 172 5.17 Binding Reputation Engine and Console . . . . . . . . . . . . . . . . . . 174 5.18 Reputation Engine for PeerTrust . . . . . . . . . . . . . . . . . . . . . . 175 5.19 Reputation Engine for REGRET . . . . . . . . . . . . . . . . . . . . . . 177 xviii Acronyms API Application Programming Interface .................................. 113 ASP Answer Set Programming ................................... .......... 68 CIA Confidentiality, Integrity, and Availability ............................ 202 CSA Cloud Security Alliance ........... .................................... 53 CLS Controllable Local System ............................................ 93 EHR Electronic Health Record ............................................. 59 EMF Eclipse Modelling Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 JDBC Java Database Connectivity..........................................125 JMS Java Message Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 JNDI Java Naming and Directory Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 ICT Information and Communication Technology.........................143 NESSoS Network of Excellence on Engineering Secure Future Internet Software Services and Systems ................................................. 59 OCL Object Constraint Language .......................................... 88 OODBMS Object-Oriented Database Management System......................127 P2P Peer-to-Peer ........................................... . . . . . . . . . . . . . . . . 5 QoS Quality of Service.....................................................29 RDBMS Relational Database Management System............................119 SDLC System Development Life Cycle ........................................ 2 SLA Service Level Agreement .............................................. 50 SSE Secure System Engineering.............................. . . . . . . . . . . . . . . .1 xix LISTINGS SQL Structured Query Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 UML Unified Modeling Language .. . . . . . . . . . . . . . . . . . . . . . . . . . ................ 12 UML4PF UML Profile for Problem Frames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 WSDL Web Service Description Language...................................131 XML eXtensible Markup Language ......................................... 23 xx Chapter 1 Introduction The aim of this chapter is to set the context of this thesis and to introduce its motivation, goals and contributions. This thesis is framed along the intersection of two important research areas: Secure System Engineering (SSE) and trust management. Therefore, in Section 1.1 we provide some background knowledge on these areas, stressing the difference between trust and other related concepts like security, risk and trustworthiness. After setting the context of the thesis, we present the goals that it pursuits in Section 1.2, which also summarizes the main contributions and explains how they fit in the context of the thesis. Finally, Section 1.3 provides the list of publications that underpins the thesis, and the funding that allowed its realization. 1.1 Research Scope This section introduces the scope of the thesis, which moves along the intersection of two research areas: SSE and trust management. The former is introduced in Section 1.1.1 and concerns with building secure systems from the ground-up. The latter, presented in Section 1.1.2, aims to translate the concept of trust into the computing domain. The concept of trust is closely related to and has been traditionally mixed up with other concepts such as security, risk and trustworthiness. Therefore, Section 1.1.3 clarifies the intuitive relationships between these concepts, stressing their differences. 1 1. INTRODUCTION 1.1.1 Secure System Engineering The domain under which this thesis is framed is Secure System Engineering, which is an evolving discipline that unifies two important areas: system engineering and security (131) (4). The discipline takes a holistic view of security across all phases of the System Development Life Cycle (SDLC), from the initial planning and specification of security requirements to the runtime verification of security properties, as depicted in Figure 1.1. The growing importance of this discipline is reflected by industry initiatives like the Microsoft Security Development Lifecycle1, by the creation of working groups in the area2, and by EU-funded projects3. Figure 1.1: Secure System Development Life Cycle Planning'and' Visualiza-on' Security' Analysis' Secure'' Design' Secure' Implementa-on' Run-me' Verifica-on' Risk' Management' Assurance' The discipline takes a proactive side in securing systems (and in turn, the services that constitute them) as opposed to the traditional reactive approach that has been the standard in the security field (42)(131). This reactive approach has been proven to be problematic because security breaches are tackled once the harm is already done, with the subsequent loss of large amount of money and reputation (130). On the contrary, SSE proposes building the system secure from the ground-up, limiting the attack surface of the system from the very beginning, and ensuring that the enforcement of security mechanisms matches their initial specifications (35). 1http://www.microsoft.com/en-us/sdl/ 2http://www.ifip.org/bulletin/bulltcs/tc11_aim.htm 3http://www.nessos-project.eu 2 1.1 Research Scope The first phase of the SDLC, namely planning and visualization, studies the feasibility of the system and makes some early decisions in relation to its development. During security analysis, threats to the system, as well as security goals and concerns for the different stakeholders, are elicited. Next, design artifacts and an architecture are built in order to provide the security services that prevent the threats and that cover the security needs identified in the previous stage. This architecture is implemented in the next phase, where best practices in secure coding and secure execution platforms are used. In service-oriented environments, where systems are built by composing services, there is the need to consider secure composition platforms and approaches. The last phase of the cycle includes the runtime monitoring of the system in order to verify the enforcement of the security requirements and policies defined in previous phases. Transversally to the cycle and controlling the flow of the different activities, risk management and assurance operations are executed. The former identifies and quantifies risks that may endanger the successful achievement of the system, whereas the latter is concerned with guaranteeing that the security goals and requirements are preserved all along the cycle4. As further discussed in Section 1.2, this thesis focuses on engineering trust in several phases of this SDLC. Therefore, the next section provides some background knowledge on the area of trust management. 1.1.2 Trust Management The term trust management dates back to the mid 90s and was coined by Blaze, Feigenbaum and Lacy (18) to denote new mechanisms for decoupling the identity from the authorization problem. In particular, these mechanisms simplify the two-step access control process, namely an authentication step and an authorization step, into a onestep trust decision. Another approach to introducing trust in the computing domain was formerly proposed by Marsh (75). In this approach, namely computational trust, the idea is to study how trust is characterized in other disciplines, like psychology, game theory or economics, and replicate this trust knowledge in the computing domain for collaborative scenarios. The main difference with the traditional view of trust management is that 4There are different life cycles models, and some of them include phases like maintenance. Nonetheless, we abstract from concrete models and represent the crucial phases that most of them share. 3 1. INTRODUCTION •A conceptual framework that analyses trust-related concepts and the relationships among these concepts, which in turn provides a common basis that allows comparing a wide range of trust and reputation models. •A methodology to incorporate trust reasoning during Cloud sourcing decisions in the early phases of the SDLC. •A methodology and tool that support the identification of threats in systems and organizations through the analysis of trust relationships. •A methodology and notation that allows the elicitation of trust and reputation requirements and their integration with other functional and non-functional (including security) requirements. •A notation that allows the specification of trust and reputation models into the system. •A framework that allows the implementation of a wide range of trust and reputation models. •A framework that allows building systems that evolve at runtime according to trust and reputation values. Figure 1.2 shows how these contributions are aligned with the different phases of the SDLC. 1.2.2 Thesis Outline In this first chapter, we have contextualized this thesis in the scope of trust engineering, and we have summarized its contributions in relation to this scope. In Chapter 2, we first provide a comprehensive literature review that analyses trust attending to different points of view. This analysis provides the required background to elaborate a conceptual framework that conveys trust-related concepts and their relationships. This framework serves as a basis for a systematic comparison of different trust and reputation models, decoupling them from particular assumptions and lowlevel details. The conceptual framework gathers three sets of concepts. The first set corresponds to concepts that are common to all the trust models in the literature, and 10 1.2 Goals and Organization Figure 1.2: Main Contributions in relation to the SDLC Planning'and' Visualiza-on' Security' Analysis' Secure'' Design' Secure' Implementa-on' Run-me' Verifica-on' Risk' Management' Assurance' - Trust-based Threat Analysis - Trust Requirements Elicitation - UML Profile for Trust and Reputation Specification - Development Framework for Trust and Reputation Models - T[email protected] framework - Trust-supported Cloud Sourcing Decision which include the factors that influence trust, the roles that entities may play, and the purpose of trust, among others. The second and third sets of concepts refer to concepts related to two classes of trust models that we consider, namely decision and evaluation models, respectively. The former revolve around the concepts of policies and credentials, whereas the latter put the stress on the assessment of trust, including trust metrics, trust factors and the sources of information. The conceptual model is used to compare a wide range of well-known trust and reputation models. The knowledge elicited by the conceptual model is put into practice in the subsequent chapters, where we discuss methodologies, notations and tools to integrate trust in different phases of the SDLC. Thus, in Chapter 3, we focus on the early phases of the cycle, spanning the planning, analysis and design phases. As for the former, we tackle an important activity that is attracting the attention during the last years: the outsourcing of the system, or part of it, to a cloud provider. We present a methodology that supports the trust evaluation of different cloud providers according to several dimensions. This information proves to be useful when there is lack of complete information (i.e. in the presence of uncertainty) in order to minimize the probabilities of problems derived from a wrong decision, such as security or privacy incidents. The methodology requires a phase of knowledge gathering from different sources about the cloud provider. This knowledge is represented by confidence intervals, which allows representing uncertainty 11 1. INTRODUCTION explicitly. We also define an operator in order to aggregate intervals while maintaining uncertainty in each operation. The methodology output consists of a set of confidence intervals that reveals to what extent the trust in the provider differs from the initial expectations. The methodology is applied to four well-known cloud vendors under an eHealth case study. We also integrate trust in two activities that are typically performed during the security analysis phase. The first one involves the analysis and identification of insider threats in socio-technical systems. In such systems, the organization is a key player and as such, its components and relationships must be taken into account. Therefore, by detecting implicitly assumed and misplaced trust relationships, we can infer potential threats on resources in terms of confidentiality, integrity and availability. The second contribution in this phase corresponds to an extension over the problem frames notation in which trust and reputation concepts are integrated. Therefore, by using this extension we are capable of eliciting trust and reputation requirements, integrating them with other functional and non-functional requirements. After the requirements analysis, we move to the design phase, where an initial specification of the system with trust and reputation considerations is proposed. In order to accomplish this task, a Unified Modeling Language (UML) profile that extends several diagrams is presented. The concepts included in the profile allow designers to specify trust and reputation solutions that can be easily implemented in later stages. Not only do the profile support the description of how trust and reputation is computed, but it also enables reasoning about the purpose of trust, and in particular, for which use cases trust, reputation or both are required and why. The extended diagrams include use case, class and deployment ones. Even when sequence diagrams are not extended, we encourage their use in order to represent the interaction patterns between the system and the trust models. The profile is validated with an eHealth scenario, where physicians monitor patients through wearables that send vital signs information to the hospital servers. In this setting, it becomes very important to consider trust requirements that encompass trust relationships between patients, physicians and the wearables, as well as reputation information about the physicians. Despite the vast amount of trust models proposed in the literature, few effort has been made on smoothing their implementation in more general contexts. Developers feel unarmed when it comes to implement these models because there are no tools or clear 12 1.2 Goals and Organization guidelines on how to integrate trust models in their own systems. Therefore, Chapter 4 describes a framework that developers can use in order to implement a wide range of trust and reputation models. The requirements of the framework and its high-level architecture are discussed first, and as it is the case with the aforementioned contributions, they build upon the concepts identified in Chapter 2. Then, a low-level architecture and guidelines towards the implementation of its different aspects are introduced. The framework is designed to act as a middle-tier server that mediates between the client application and the database tiers, where the application can request trust information or send updates of trust or reputation values. The framework empowers developers to define their own metrics and the events in the application that trigger trust and reputation updates. The validation is done in the context of a social market for cloud providers, in which they can publish web services and consume services from other providers. The use of trust and reputation in order to evolve the system at runtime is discussed in Chapter 5. In particular, we describe a development framework for trust and reputation models that is integrated in a mo[email protected] platform. Mo[email protected] is a model-driven approach that allows reasoning about a running system by means of abstractions. This approach is gaining traction among the model-driven community because it helps tackling the complexity of distributed systems and due to its selfadaptability capabilities: users can use the platform in order to reason about the state of the system and can easily determine whether a reconfiguration is required given some changing conditions. These platforms however do not usually consider security aspects, which may be a stumbling block for its widespread adoption. Therefore, the framework that we propose enables developers to include trust and reputation reasoning in the system components, which yields trust-aware systems that self-adapt at runtime based on trust and reputation values. We validate our framework in a distributed chat application by implementing several well-known trust and reputation models. We also prove that our framework entails negligible computational overhead and entails minimal effort for developers. Chapter 6 finalizes the thesis by presenting the conclusions as well as some open research problems that require further attention from the research community. 13 1. INTRODUCTION 1.3 Publications and Funding The contributions of this thesis have been presented in various journals and international conferences. Next, we provide a list of the contributions organized by the type of publication: Journal article ISI-JCR •F. Moyano, C. Fernandez-Gago, and J. Lopez. A Framework for Enabling Trust Requirements in Social Cloud Applications. In Requirements Engineering, vol. 18, issue 4, Springer London, pp. 321-341, Nov 2013. ISI JCR Impact Factor: 1.675 International Conferences •F. Moyano, K. Beckers, and C. Fernandez-Gago. Trust-Aware Decision-Making Methodology for Cloud Sourcing. In 26th International Conference on Advanced Information Systems Engineering (CAiSE 2014), M. Jarke, et al. Eds., LNCS 8484, Springer, pp. 136-149, Jun, 2014 •F. Moyano, C. Fernandez-Gago, and J. Lopez. Building Trust and Reputation In: A Development Framework for Trust Models Implementation. In 8th International Workshop on Security and Trust Management (STM 2012), A. Jøsang, P. Samarati, and M. Petrocchi Eds., LNCS 7783, Springer, pp. 113-128, 2013 •F. Moyano, B. Baudry, and J. Lopez. Towards Trust-Aware and Self-Adaptive Systems. In 7th IFIP WG 11.11 International Conference on Trust Management (IFIPTM 2013), C. Fernandez-Gago, I. Agudo, F. Martinelli, and S. Pearson Eds., AICT 401, Springer, pp. 255-262, Jun 2013 •F. Moyano, C. Fernandez-Gago, and J. Lopez. A Conceptual Framework for Trust Models. In 9th International Conference on Trust, Privacy & Security in Digital Business (TrustBus 2012), S. Fischer-Hübner, S. Katsikas, and G. Quirchmayr Eds., LNCS 7449, Springer Verlag, pp. 93-104, Sep 2012 •F. Moyano, C. Fernandez-Gago, and J. Lopez. Towards Engineering Trust-aware Future Internet Systems. In 3rd International Workshop on Information Systems 14 1.3 Publications and Funding Security Engineering (WISSE 2013), X. Franch, and P. Soffer Eds., LNBIP 148, Springer-Verlag, pp. 490-501, Jun 2013 •F. Moyano, C. Fernandez-Gago, K. Beckers, and M. Heisel. Enhancing Problem Frames with Trust and Reputation for Analyzing Smart Grid Security Requirements. In Second International Workshop on Smart Grid Security, J. Cuellar Ed., LNCS 8448, Springer, pp. 166-180, Aug, 2014 Book Chapter •F. Moyano, C. Fernandez-Gago, B. Baudry, and J. Lopez. Engineering TrustAwareness and Self-adaptability in Services and Systems. In Engineering Secure Future Internet Services and Systems, vol. LNCS 8431, no. 8431, Springer, pp. 180-209, 03/2014 Additionally to these main contributions, there are other works that have been carried out in parallel and which are listed next sorted by date: •K. Beckers, M. Heisel, F. Moyano and C. Fernandez-Gago, Engineering Trustand Reputation-based Security Controls for Future Internet Systems. In The 30th ACM/SIGAPP Symposium On Applied Computing (SAC 2015), In Press •F. Paci, C. Fernandez-Gago, and F. Moyano. Detecting Insider Threats: a TrustAware Framework. In 8th International Conference on Availability, Reliability and Security, IEEE, pp. 121-130, Nov 2013 •F. Moyano, C. Fernandez-Gago, and J. Lopez. A Trust and Reputation Framework. In Doctoral Symposium of the International Symposium on Engineering Secure Software and Systems (ESSoS-DS 2013), M. Heisel, and E. Marchetti Eds., CEUR-WS 965, CEUR-WS, pp. 7-12, 2013 •F. Moyano, C. Fernandez-Gago, and J. Lopez. Service-Oriented Trust and Reputation Architecture. In Proceedings of the Doctoral Symposium of the International Symposium on Engineering Secure Software and Systems (ESSoS-DS 2012), J. Cuellar, and N. Koch Eds., CEUR-WS 834, CEUR-WS, pp. 41-46, 2012 15 1. INTRODUCTION This dissertation has been possible thanks to the support and funding of the Spanish Ministry of Education through the National Programme for Training Human Resources under the FPU (Training of University Lecturers) fellowship. Furthermore, some parts of this work have been supported by and applied to different National and European projects: NESSoS (FP7 256980), ARES (CSD2007-00004), SPRINT (TIN2009-09237), FISICCO (P11-TIC-07223), and PISCIS (TIC-6334). 16 Chapter 2 Understanding Trust: A Systematic Analysis The aim of this chapter is setting up some foundations onto which we can build the rest of the chapters of this thesis. Prior to integrating trust and reputation in the different phases of the SDLC, it is necessary to systematize the knowledge around these notions. Gaining insight on trust and trust-related concepts demands a wide study of the concept of trust that spans different angles, which include revising the origins of trust management and computational trust, reviewing existing taxonomies and trust and reputation surveys, and analyzing how the concept of trust has being approximated to each phase of the SDLC. Once we gather this knowledge, we proceed by creating a conceptual model where the most relevant trust-related concepts are stressed and related among them. This model serves us as a framework to compare different trust models under the same lens, and at the same time, it provides the basis and the core knowledge that can be integrated in different phases of the SDLC, from the early phases (Chapter 3) to runtime (Chapter 5). The chapter consists of two main sections. Section 2.1 reviews existing works that consider trust in different contexts and phases, whereas Section 2.2 presents the conceptual model and applies it in order to compare a wide variety of trust and reputation models. 17 2. UNDERSTANDING TRUST: A SYSTEMATIC ANALYSIS 2.1 Literature Review This section summarizes existing works on trust from three different perspectives: •Taxonomy perspective: these works provide a classification or taxonomy of trust and reputation concepts and models. •Computing domain perspective: here we tackle the origins of trust management and computational trust through a revision of the two main classes of trust models. •Development life cycle perspective: we deal with works that aim to integrate trust in different phases of the SDLC. Each of the following sub-sections deal with these perspectives in further detail. 2.1.1 Trust Taxonomies Grandison and Sloman (43) provide a classification of trust based on its purpose. The first purpose is trusting a trustee to access the resources of a trustor. The second purpose is trusting a trustee to provide a resource to a trustor. Certification of trustees is the next purpose; in this case, trustee’s identity or capabilities are certified by a third party. The next purpose is delegation, in which a trustor trusts a trustee to make decisions on its behalf. Finally, the authors discuss infrastructure trust, where trustors trust themselves (implicit trust) and the infrastructure that they use, including firmware, operating systems, local network and servers. Trust is relevant in multi-agent systems, since agents must trust other agents in order to engage in collaborations. In this context, Ramchurn, Huynh and Jennings (104), and Sabater and Sierra (115) have provided their own conceptualisation of trust models. The former categorize trust in individual-level trust, which refers to beliefs on the honesty of other agents, and system-level trust, which involves trust as a consequence of adjusting to the rules of encounter or protocols. The latter proposes several classification dimensions for trust and reputation models. The first dimension is the conceptual model, which can be cognitive (trust as a set of beliefs) or game-theoretical (trust as an outcome of an interaction). The second dimension comprises the information sources used to gather knowledge and to make a trust decision; these sources include direct experience, witness information, sociological information and prejudice. The next 18 2.1 Literature Review dimension is visibility types, which refers to whether trust is seen as a global property shared by all observers or is observed as a subjective property assessed particularly by each individual. Another criteria is the granularity of the model, which determines whether the model serves for a single context or allows multiple context at a time. The assumptions about agent behaviour is the next criteria; some models assume that agents may behave badly, whereas others assume that cheating behaviour will not happen. The type of information received from witness is another criteria, and the authors consider those models that use boolean information and continuous measures. Finally, the authors consider whether the model uses a reliability measure of the trust value. In relation to multi-agent systems, Pinyol and Sabater-Mir (98) present a survey on classification dimensions by other authors under this context, and they provide their own classification dimensions. The first one is the trust dimension, where they distinguish between trust and reputation model. Essentially, the authors state that trust implies a decision, and only when the decision-making process is part of the model (e.g. the model provides a threshold computation), the model is actually a trust model. The second one is the cognitive dimension, and it refers to whether the model explicitly model the reasons behind a trust disposition, that is, if it is possible to reason about a trust decision in terms of beliefs. The next dimension is procedural, and evaluates whether the model explains the bootstrapping phase. Finally, the generality dimension states whether a model is designed for a very particular scenario or can be adapted to a variety of scenarios. The life cycle of a trust management system is discussed by Ruohomaa and Kutvonen (113). According to the authors, this life cycle starts with the initialization of a trust relationship, where an entity uses a discovery service to find a partner. The second phase is observation, where an the behaviour and interactions of an entity are observed. In this context, intrusion detection and prevention systems may be used as a source of information for updating trust and reputation values. The next phase consists of evolving trust and reputation. As part of this phase, it is necessary to translate experiences into updates in reputation. The same authors also compare several reputation systems under a credibility taxonomy (112). They advocate that in open reputation system environments, different types of misbehaviour can occur, making it important to separate accurate from inaccurate information. This credibility taxonomy comprises three criteria: the creation and content of a recommendation, the selection 19 2. UNDERSTANDING TRUST: A SYSTEMATIC ANALYSIS diagrams in order to represent trust information. We also propose a UML profile for trust, which is described in Chapter 3. However, their approach and focus are different than ours. For example, we consider reputation information and put the stress on how trust and reputation is to be updated and represented, which is laid aside by UMLtrust. Other works aim to integrate the notion of risk into the requirement analysis stage. As an example, Lund, Solhaug and Stølen (70) present CORAS, a risk analysis methodology that analyses unwanted incidents for a defined asset model, and when the risk level of those unwanted incidents is beyond an acceptable threshold, several treatments are introduced to the system. Asnar, Giorgini and Mylopoulos (6) propose a concrete methodology, namely the Goal-Risk framework, to analyse and model security problems. It captures the stakeholders’ goals, risks that might threaten the goals, and countermeasures required to mitigate the unacceptable risks. Even when the concepts of trust and risk are related (see Section 1.1.3), they present several differences that justify a particular attention on trust. In this direction, the former approaches towards trust in the early stages of the SDLC come from policy languages for distributed trust management. Three remarkable examples are PolicyMaker (18), REFEREE (28) and SULTAN (44), which are further discussed in Section 2.1.2.1. This is however a very limited scope of trust and does not take into account behavioural aspects, reputation and social relationships to determine trust. Some methodologies have aimed at a wider definition of trust, presenting methodologies to build secure systems by taking relationships between actors and agents into account. In this regard, some authors have based their work upon goal-driven methodologies to represent dependencies among actors and their views of the system. Some examples include Secure Tropos (83), KAOS (129) and SI* (77). The first one is a methodology that extends the Tropos methodology in order to enable the design of secure systems. Actors in Tropos may depend on other actors in order to achieve a goal. Tropos captures the social relationships in the system by specifying the dependencies between actors using the notions of depender, dependum and dependee, and by modeling the actors and agents in the organization. SI* is similar, as it is based on analysing social dependencies among stakeholders, although it does not constitute a methodology on its own. SI* allows specifying the goals and views of all stakeholders of a system, considering relevant software artificats to these goals and 26 2.1 Literature Review modelling stakeholder relations based upon structured goal models. In Chapter 3, we build a trust model upon SI* in order to detect insider threats. As for KAOS, it is another goal-driven methodology, not so focused initially on security aspects. However, some posterior extensions (128) introduce the concepts of obstacle and anti-goal in order to analyse some trust concerns of a system. KAOS obstacle captures an undesired state of affairs that might harm safety goals (i.e., hazard) or threaten security goals (i.e.,threat), while KAOS anti-goal captures the intention of an attacker. The analysis of social relationships is taken one step further in the works by Li, Liu and Bryant (65), Elahi, Yu and Zannone (32) and Liu, Yu and Mylopoulos (67), where actor dependency links are used as a way to identify and analyse system vulnerabilities. The aforementioned contributions put forward the idea of capturing social aspects, but they usually fail in capturing and making all the trust relationships explicit, and above all, how trust and reputation can be used by the system-to-be. Pavlidis, Mouratidis and Islam (84) extend the Secure Tropos modelling language in order to include some trust-related concepts. In particular, they support the analysis of dependencies between actors and between actors and resources. By analysing the level of trust of these dependencies, they can determine whether an actor can be trusted to fulfil a dependency. Trust is also integrated in Role-Base Access Control model (25) by means of trust levels and a trust vector, where each component in the vector is a factor that influences trust, such as knowledge or experience. 2.1.3.2 Trust in Implementation Few works provide developers with methodologies or tools with which they can implement different types of trust and reputation models. Suryanarayana, Diallo and Taylor (123) propose the 4C framework, where they describe a trust model as a composition of four sub-models, namely the content sub-model, the communication sub-model, the computation sub-model and the counteraction sub-model. For each sub-model, they identify the main building blocks that are present in existing reputation models. In the end, using an Java-based editor and following a personalized XML schema, they create a XML document where a trust model is described according to these building blocks. Then, they can use the PACE Support Generator to create software components that integrate within the PACE architectural style, which is further described in the work 27 2. UNDERSTANDING TRUST: A SYSTEMATIC ANALYSIS by Suryanarayana et al. (122). In this latter work, the authors study the feasibility of an event-based architectural style in order to provide architects with guidelines on how to include trust models into decentralized applications. While the application scope of the previous framework is general, the Pythia (135) framework targets owners of blog sites who want to integrate reputation dynamics in the latter. This framework follows a plug-in architecture, where plug-ins provide the instantiation required for a concrete domain (i.e. a concrete web site). Therefore, a user who wants to use a Pythia-based system should first download the plug-in for that specific system. An important component of the framework is the rules engine, which is edited by users to decide how reputation is to be evaluated. The accommodation and integration of different trust or reputation models is also addressed. For example, Lee and Winslett (62) propose an extensible framework that supports the adoption of different negotiation-based trust models. The framework abstracts away concrete implementation details of different negotiation models and provides generic building blocks that allow implementing new ones. In a similar direction, although more focused on tackling the context dependency of trust, Huynh (53) proposes the Personalized Trust Framework (PTF). This framework consists of a rule-based system that uses semantic technologies (e.g. ontologies) to capture expert knowledge about different contexts and to apply the most suitable trust model according to these contexts. The idea is to replicate the trust evaluation process carried out by humans in a computational setting, because humans are capable of determining the context under which a trust evaluation is to be performed. Customizable trust models are another design and implementation aid. Examples of these are the SECURE platform (23) and SCOUT (48). They do not provide much flexibility with regards to implementing new models, because they are bound to an underlying model. However, they allow their customization by defining or changing some of the inner components. The former relies on a cost-benefit analysis represented by combined cost-PDFs (Probability Density Functions). The idea is, for every possible outcome of an action, to consider all possible costs and benefits the user might incur in. If the final combined cost-PDF shows that the benefits outweigh the other outcomes’ costs, then the action proceeds. Otherwise, further interaction is arranged. The latter is made up of three services that implement the model: the evidence gathering service, the belief formation service and the emotional trust service. 28 2.1 Literature Review Vinkovits, Reiners and Zimmermann (132) present a user-centered approach that allows non-security experts to include trust and reputation into their applications. The approach is a model-driven system that starts by allowing users to select several trust requirements. From these requirements, the system proposes different trust frameworks, which have been previously implemented by trust experts. After choosing one of these frameworks, users can fill in the remaining code in order to adapt it to their particular applications. 2.1.3.3 Trust at Runtime There is a growing interest in how trust can assist evolving systems over their lifetime. Self-adaptive systems can take trust and reputation information in order to leverage runtime reconfiguration decisions, especially in the areas of multi-agent systems, component-based systems and service-oriented systems. In some cases, trust is considered in its hard variant, where trust is seen as an aggregation of Quality of Service (QoS) and security properties. In other works, the soft variant of trust is used (106), which means that social aspects such as reputation or preferences are taken into account. As mentioned earlier, trust is seen as a powerful tool to leverage decision-making even with partial information. This fact is especially remarked in STRATUS (110), a set of technologies that aim at predicting and responding to complex cyber attacks. When it detects an attack, the platform switches to back-up components and finds alternative pathways of communication. The trust model that supports this platform (109) is based on conditional trust, that is, trust in certain capabilities of a system. The authors argue that experience-based trust is not useful because configurations in cyber attacks change frequently, laying statistical analysis useless. They propose ways to make the most out of the little information available, and they introduce concepts like contagion that allows formalizing trust in a host based on the distance from an infected host. A classical scenario of application of trust is multi-agent systems (104), where Vu et al. (133) propose trust-based mechanisms as a way to self-organize the agents in case of deceitful information. In particular, the trust value of an agent towards another one is an aggregate of direct experiences and testimonies. The use of artificial intelligence, and concretely, machine learning together with trust in order to adapt the behaviour of agents is proposed in the work by Klejnowski, Bernard, Hähner and Müller-Schloer 29 2. UNDERSTANDING TRUST: A SYSTEMATIC ANALYSIS (60). They propose an architecture where there is an observer component that gathers information about the agent and presents it to the controller in two views: a longterm and a short-term one. The controller finds a suitable behaviour according to this information. Given that new unexpected situations might arise, agents must be able to try out new strategies and learn which ones provided the best results. Given the highly open and distributed nature of service-oriented environments, the traditional use of trust is for either protecting providers from potentially malicious clients or for shielding clients against potentially malicious providers (e.g. providers that publish a higher QoS than offered). As an example of the first situation, Conner et al. (29) present a feedback-based reputation framework to help service providers to determine trust in incoming requests from clients. As an example of the second approach, Crapanzano et al. (31) propose a hierarchical architecture for SOA where there is a so-called super node overlay that acts as a trusting authority when a service consumer looks for a service provider. In both, componentand service-oriented systems, an important research area is determining the level of trust, or the trustworthiness, of the system as a whole, or of individual subsystems (i.e. services or components). In case that the trust value is too low, a reconfiguration takes place in order to try to improve it. In this direction, Haouas and Bourcier (47) present a runtime architecture that allows a service-oriented system to meet a dependability objective set up by an administrator. System dependability is computed by aggregating ratings provided by service consumers regarding QoS attributes. Then, a reconfiguration manager may look up other available services to meet the dependability objective. Dependability of the system is computed by the aggregation of each service dependability. In turn, each service dependability is computed by aggregating a weighted average of ratings provided by service consumers regarding QoS attributes (e.g. response time) of service providers. The reconfiguration manager is in charge of querying the service broker to find the available services that can meet the dependability objective. Following a similar line of work in component-based systems, Yan and Prehofer (139) discuss an adaptive trust management system where several quality attributes can be used to rate the trustee’s trustworthiness, such as availability, reliability, integrity or confidentiality. Assessing these attributes requires defining metrics and placing monitors 30 2.1 Literature Review to measure their parameters. Finally, trust is assessed at runtime based on the trustor’s criteria and is automatically maintained by changing among trust control modes. These previous works are highly focused on QoS-based trust, where trust is an aggregation of dependability and security attributes. Subjective factors affecting trust and reputation concepts, with which we deal, are out of discussion. The social notion of trust is used by Psaier et al. (100) in their self-adaptation framework. In particular, their trust model uses the concept of trust mirroring and trust teleportation. The former implies that actors (i.e. services) with similar interests and skills tend to trust each other more than unknown actors, whether the latter denotes that the level of trust in a member of a group is transferable to other members of the same group. The adaptations consist of reconfiguring the network by opening channels to provide new interactions and by closing channels to hinder misbehaving nodes to further degrade the system function. The trust model is used to help choose among a set of new candidate nodes with which to communicate. Another way to measure the (mis)behaviour of components is by comparing its interactions with the models in their contracts. In this direction, Herrmann and Krumm (51) propose security wrappers that monitor the activity of the components. Depending on the deviation of the components’ behaviour with respect to their contract, a positive or negative report is issued and sent to the trust information system, which calculates a trust value for the component. In turn, this trust value is used to determine the intensity of the monitoring activity by the wrappers. This scheme was enhanced by Herrmann (52) in order to take the reputation of components’ users into account so as to prevent deliberate false feedbacks. In this regard, a common problem in any setting where different entities rate each other is discerning fair from unfair ratings. Phoomvuthisarn, Liu and Zhu (97) propose a reputation mechanism for SOAs environments that allows services to retrieve other services’ reputation through auctions that ensure incentives for truthful reporting. Other works focus on the self-adaptation of trust models to match and reflect the status of the system (69), and on considering the trust in the self-adaptation process itself (40). Finally, Kiefhaber et al. (59) present the Trust-Enabling Middleware, which provides applications running on top of it with methods to save, interpret and query trust related information. The middleware provides self-configuration and self-optimization and its 31 2. UNDERSTANDING TRUST: A SYSTEMATIC ANALYSIS goal is balancing the workload of nodes by relocating services. The middleware also uses built-in functions to measure the reliability of nodes by considering packets losses. 2.2 Trust Conceptual Model In this section, we introduce and discuss our trust conceptual model, which builds upon the knowledge gathered in the previous sections. The goal of this model is to abstract away the particularities of concrete trust models and to provide a consistent set of concepts and relationships among these concepts that assist the comparison of different classes of trust models, as well as the integration of trust concerns in different phases of the SDLC. In the following sub-sections, we elaborate on the definition of trust and depict some of the most relevant concepts that are related to this notion. Then, the concept of trust model is introduced and a classification of trust models is provided. This classification is used as the basis to decompose the concepts that underlie in trust models, which we describe next. Finally, we describe how we use these concepts as a yardstick for comparing different well-known trust and reputation models. 2.2.1 Trust Definitions Many definitions of trust have been provided over the years. This is due to the complexity of this concept, which spans across several areas such as psychology, sociology, economics, law, and more recently, computer science. The vagueness of this term is well represented by the statement “trust is less confident than know, but also more confident than hope” (82). In this section, we revise the definitions that have been mostly considered in the literature of computational trust and reputation models. We advocate that making an effort to understand this term and its implications is crucial if we want to implement meaningful models. On the other hand, understanding trust and reputation allows for a better trust-related concepts identification as well as for building a more comprehensive conceptual framework for trust models comparison. Definitions are presented in chronological order. Gambetta (37) defines trust as “a particular level of the subjective probability with which an agent will perform a particular action [. . .] in a context in which it affects our 32 2.2 Trust Conceptual Model Table 2.1: Trust Definitions 1988 1991 1995 1996 2000 2002 2005 2011 (37) (20) (78) (80) (43) (85) (104) (91) (113) (142) (48) own action”. Mayer, Davis and Schoorman (78) advocates that trust is a “willingness to be vulnerable to another party”. McKnight and Chervany (80) explain that trust is “the extent to which one party is willing to depend on the other party in a given situation with a feeling of relative security, even though negative consequences are possible”. Mui, Mohtashemi and Halberstadt (85) define trust as “a subjective expectation an agent has about another’s future behavior based on the history of their encounters”. For Olmedilla et al. (91), “trust of a party A to a party B for a service X is the measurable belief of A in that B behaves dependably for a specified period within a specified context (in relation to service X)”. Ruohomaa and Kutvonen (113) state that trust is “the extent to which one party is willing to participate in a given action with a given partner, considering the risks and incentives involved”. Finally, Har Yew (48) defines trust as “a particular level of subjective assessment of whether a trustee will exhibit characteristics consistent with the role of the trustee, both before the trustor can monitor such characteristics (or independently of the trustor’s capacity ever to be able to monitor it) and in a context in which it affects the trustor’s own behavior”. Table 2.1 summarizes all the definitions used as inputs to build the concepts cloud depicted in Figure 2.1. Definitions were processed following several rules. A word that appears several times in the same definition is counted just once. We only take into consideration words that mean something by themselves and do not require surrounding words to mean something (e.g. particular level does not make sense separately). If two words with the same meaning appear either in plural and singular, it is expressed in singular. Dependability is split into security and reliability. Party, agent, entity, trustor and trustee are named as entity. Most words are adjectives and nouns, since they are more meaningful without a context than verbs, but some relevant verbs are considered as well. Assessment is used in place of quantifiable,measurable,describable and alike terms. The resulting concepts were introduced in Wordle2. 2http://www.wordle.net/ is a free online tool to generate words clouds. 33 2. UNDERSTANDING TRUST: A SYSTEMATIC ANALYSIS Figure 2.1: Concepts Cloud for Trust Definitions The figure reveals that entity is the core concept, which is obvious as trust makes no sense if there are neither entities that trust nor entities in which to trust. Context is another relevant concept since trust is highly context-dependent. Other important concepts entail uncertainty such as subjective, belief, willingness or expectation. They show that trust implies uncertainty about an entity’s behaviour. It is also important to note that even though the concept of risk is not explicitly present in all the definitions, a careful reading reveals that it is indeed implicitly considered in almost all of them. For example, in his definition, McKnight (80) states that “.. . negative consequences are possible”, and Mayer (78) claims that trust is willingness to be vulnerable. As a wrap-up, the notion of trust is present when there is uncertainty and risk during the interaction of two or more entities that need to collaborate in a particular context. If the entity placing trust knows the outcome in advanced without any uncertainty, trust is not necessary. If the entity placing trust knows that there is no risk involved in the outcome of the interaction, trust is not necessary. If there is no interaction between two entities, trust may still make sense, but it is not necessary either. After our review and given that no definition covers all the concepts that we believe are the most important, we propose the following definition: trust is the personal, unique and temporal expectation that a trustor places on a trustee regarding the outcome of an interaction between them that affects the trustor. 2.2.2 Trust Models: Definition and Classification A trust model is an abstraction of the dynamics of trust and defines the way to specify and evaluate trust relationships among entities for calculating trust. Another way of 34 2.2 Trust Conceptual Model defining a trust model is as the technical approach to represent trust for the purpose of digital processing (140). Trust models are very heterogeneous due to many factors, including the trust definition on which they are built or their application domain. In order to provide a conceptual framework for trust models we first establish a high-level classification. Note that this task is not straightforward and other classifications have been proposed (5). We advocate that the following classification covers the two main branches that gave rise to the adoption of trust in the computational world, as further described in Section 2.1.2. •Decision Models. Trust management has its origins in these models (18). They aim to make more flexible access control decisions, simplifying the two-step authentication and authorization process into a one-step trust decision. Policy models and negotiation models fall into this category. They build on the notions of policies and credentials, restricting the access to resources by means of policies that specify which credentials are required to access these resources. •Evaluation Models. These models have their origin in the work by Marsh (75). Their intent is to evaluate the level of trust that an entity can place on another entity by considering factors that have an influence on trust relationships. An important sub-class of the former are propagation models, in which existing trust relationships are exploited to generate new trust relationships. Another important sub-class are reputation models, where a reputation scored is derived from the aggregation of other entities opinions. Making a classification is important as it eases the extraction of common features between different classes of models. It is not useful to compare decision models such as PolicyMaker (18) with evaluation models like eBay’s reputation system (107), because their nature, workings and purposes are completely different. However, comparison makes sense within each model class, because models in the same class exhibit similar features that can be compared. The next section elaborates on the underlying concepts of trust models. 35 2. UNDERSTANDING TRUST: A SYSTEMATIC ANALYSIS 2.2.4 Comparison Framework: A Case Study Not only do the concepts identified in the previous sections provide insight on computational trust, but they also allow comparing trust models under the same lens. As a way to validate our framework, we have chosen a set of relevant trust and reputation models that represent the classes discussed earlier. The models are Marsh’s model (75), PolicyMaker (18), Jøsang’s belief model (55), REGRET (114), TrustBuilder (136), eBay reputation model (107), Falcone et al. (33), Trust−X(15), PeerTrust (137) and Agudo et al. (1). As depicted in Figure 2.5, the comparison framework allows comparing trust models at two different layers. At a higher level, the framework compares different classes of trust models with regard to the common concepts. Then, models belonging to the same class are compared according to class-specific concepts. The classes are those discussed in Section 2.2.2, and we incorporate pure propagation models because even when we consider them a special class of evaluation model, they might lack some of the evaluation models concepts. Figure 2.5: General Framework for Trust Models Comparison Purpose( Class( …" Policy( Creden1al( …" Source(of( informa1on( Value(Type( …" Common%Concepts% Class%=%Decision%Model% Class%=%Evalua5on%Model% Considering%Propaga5on% Dissemina1on( Operators( …" Class9specific%% Concepts% Class%=%Pure%Propaga5on%Model% Table 2.2 shows the comparison among these models under the lens of their common features. In Table 2.3 we compare the trust decision models, whereas trust evaluation models are compared in Table 2.4 and Table 2.5. Note that the classification has been made according to the features explicitly presented by the corresponding authors, and 42 2.2 Trust Conceptual Model that due to the diversity of the models, in some circumstances the classification for some concepts is subjective according to our own interpretation. Table 2.2: Common Features Comparison Model Role Purpose Class Method PolicyMaker R/P AT, IT DM Linguistic TrustBuilder R/P AT, IT DM Linguistic Trust−XR/P AT, IT DM Linguistic Marsh’s T AT, PT EM Mathematical Falcone et al. T, W AT, PT EM Graphical, Mathematical REGRET R/P, W AT, PT EM Mathematical PeerTrust R/P PT EM Mathematical eBay R/P, TTP PT EM Mathematical Jøsang’s T AT, PT EM Mathematical Agudo et al. T AT, PT EM Graphical, Mathematical T=trustor/trustee, R/P=requester/provider, W=Witness, TTP = Trusted Third Party, AT=Access Trust, IT=Identity Trust, PT=Provision Trust, DM=Decision Model, EM=Evaluation Model Table 2.3: Decision Models Comparison Trust Negotiation Model P. Language C. Format CC CV Strategy ET PolicyMaker PolicyMaker PGP’s sig, X.509 cert - - - - TrustBuilder XML, IBM’s TPL X.509 cert X X X - Trust−X X-TNL X-TNL X X X X CC=Credential Chaining support, CV=Credential Verification support, ET=Evidence Type, - =undefined or not explicitly mentioned By observing Table 2.2, we observe that the purpose of decision models is often either access trust (a provider wants to protect a resource from malicious requesters) or identity trust (determine trust in a requester based on its identity), whereas the purpose of evaluation models is either protecting a requester from malicious providers (provision trust), or protecting providers from malicious requesters (access trust). 43 2. UNDERSTANDING TRUST: A SYSTEMATIC ANALYSIS Table 2.4: Evaluation Models Comparison Source of Information Model Approach Dimension C.Engine DI SI PI R TPR Marsh’s GT 1 Continuous X-X- - Falcone et al. SC 1 Fuzzy X X X X X REGRET GT 1 Continuous X X - - X PeerTrust GT 1 Continuous X- - D X eBay GT 1 Summation - - - C X Jøsang’s - 3 Flow/Belief - - - - X Agudo et al. - 1 Flow - - - - X DI=Direct Interaction, SI=Sociological Information, PI=Psychological Information, R=Reputation, TPR=Third Party Referral, C=Centralized, D=Distributed, GT=GameTheoretic, SC=Socio-Cognitive, -=undefined or not explicitly mentioned Table 2.5: Evaluation Models Comparison (II) Model Threshold Indirect Trust Calculation Uncertainty Time Marsh’s X X -X Falcone et al. - - XREGRET - - X X PeerTrust - - X X eBay - - - X Jøsang’s - X X - Agudo et al. - X- - -=undefined or not explicitly mentioned We also observe that decision models follow a linguistic modelling method, embodied in the policy and credential languages. Regarding evaluation models, most use mathematical methods. Additionally, Agudo et al. use graph theory and Falcone et al. use Fuzzy Cognitive Maps, and therefore they both use graphical and mathematical modelling methods. Regarding the roles, decision models exhibit the requester/provider pair, as they are usually intended for scenarios with Internet transactions. Evaluation models do 44 2.2 Trust Conceptual Model not usually specify concrete roles beyond trustor and trustee, except for those that include a witness that provides third-party referrals, or a trusted third party that stores reputation information. As for decision models, we see in Table 2.3 that PolicyMaker is a pure policy model, whereas TrustBuilder and Trust−Xinclude a negotiation strategy, as well as credential chaining support and credential verification. The latter also includes evidence types in order to prove that some steps of the negotiation protocol have succeeded. Table 2.4 shows that evaluation models follow a game-theoretic approach, except for Agudo et al. and Jøsang’s, which are pure propagation model, and Falcone et al., which is a socio-cognitive evaluation model. Most models provide a single-dimension value, except for Jøsang’s, which provides a vector of values that represent belief, disbelief and uncertainty. Semantics have been omitted as all trust models consider trust under some sort of subjective judgement (and not as formal measurements) and take into account general properties (and not specific ones). Regarding the sources of information, most of the models use third party referrals, except for Marsh’s4. The most complete model in terms of sources of information is Falcone et al.’s, because it considers also psychological information in terms of beliefs. PeerTrust is a distributed reputation model, whereas eBay’s is centralized. Sociological information, that is, the fact that an entity belongs to certain groups, is only used in REGRET and Falcone et al.’s. The latter also uses reputation as a factor to determine trust. Regarding Table 2.5, Marsh’s model is the only one that incorporates the computation of a trust threshold. The main difference between the two pure propagation models, namely Agudo et al.’s and Jøsang’s, is that the former does not consider uncertainty (i.e. credibility), whereas the latter does. Note that the main purpose of propagation models is trust dissemination, or in other words, the calculation of indirect trust relationships. However, Marsh’s model, even when it is not a propagation model itself, it provides the means to disseminate trust information. 4Marsh’s model tackles trust dissemination, but it does not use third party referrals for computing trust. Furthermore, we consider that the initial relationships on which the pure propagation models work are a type of third party referral 45 2. UNDERSTANDING TRUST: A SYSTEMATIC ANALYSIS 46 Chapter 3 Incorporating Trust Engineering in Early Phases of the SDLC This chapter addresses several key considerations when integrating trust in activities that are part of the early phases of development, from planning to design. During the planning phase, there is an ever-increasing need to decide whether the system or a part of it should be moved to the Cloud, activity known as cloud sourcing. This provides several benefits in terms of scalability and cost-effectiveness, but it raises security concerns as to who can access the deployed data or services. Cloud sourcing has a high impact on the design of the system outsourced, given that it entails a partial loss of control and consequently, potential threats to security. The first important decision that we must make is to which cloud vendor we are moving part of the system. This first decision can be key to the rest of the design and we advocate that trust evaluation of cloud vendors can help cushion the aforementioned loss of control and potential security problems. Along the second phase, namely security analysis, there are two important activities to cover. First, in order to achieve trust-aware solutions, we need to capture trust requirements. However, whereas the security community has traditionally focused on providing tools and mechanisms to capture and express hard security requirements (e.g. confidentiality), little attention has been paid to trust and reputation requirements. We argue that these soft security requirements can leverage security in open, distributed, heterogeneous systems and applications and that they must be included in early phases of the development process. 47 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC Another typical activity performed during this phase is threat analysis. Many threats, and particularly the ones that result in the most harmful incidents, are due to insiders. In most cases, these threats originate from false or implicit assumptions about trust relationships in the organizational context of the system. Therefore, and in order to guarantee the design of more secure systems, it is required that trust relationships are explicitly identified, analysed and quantified. From these trust relationships and modelling the criticality of the assets of the system, we can infer potential insider threats. During secure design we aim to refine the analysis artifacts into design elements that make the implementation easier and more obvious. We need to provide further insight about the rationale and the mechanics of the trust models and how they integrate into and collaborate with the system. This information is useful to sketch the first version of the system architecture and will assist developers during the implementation phase. The chapter is organized as follows. Section 3.1 describes a methodology that allows decision-makers to assess the level of trust that can be placed on a cloud provider. Section 3.2 presents a methodology to detect insider threats in a system through the analysis of trust relationships, whereas a methodology and notation to represent trust and reputation requirements is introduced in Section 3.3. Finally, in Section 3.4, we describe a UML profile that allows the specification of trust and reputation models. 3.1 Trust-supported Cloud Sourcing Decision in the Planning Phase There is an increasing trend to outsource IT services and infrastructures to the cloud (86). This model, also called cloud sourcing1, is replacing traditional outsourcing engagements due to its advantages (76). These include the provision of elastic IT resources and cost savings as a result of reduced operational costs for complex IT processes (81). Security and trust are significant barriers for the adoption of clouds in companies (99). Lack of trust in cloud providers lies within the nature of clouds: storage and management of critical data, and execution of sensitive IT processes are performed 1Techopedia: http://www.techopedia.com/definition/26551/cloudsourcing 48 3.1 Trust-supported Cloud Sourcing Decision in the Planning Phase beyond the customers control. As a consequence, new security threats arise2,3, and IT analysts and decision makers must balance the advantages and these threats before making decisions. These decisions range from selecting a cloud provider to determining how much data or which part of the infrastructure to move to the cloud. It is generally accepted the fact that trust can help in decision-making processes in the absence of complete information (45, 138). Given that information about cloud providers, due to internal policy or strategic reasons, may be uncertain and incomplete, trust can enhance the cloud sourcing decision-making process. This section presents a methodology that evaluates trust in cloud providers and that can help IT analysts to make more informed decisions prior to the sourcing process. The methodology provides a systematic way to gather knowledge about cloud providers and to exploit this knowledge in order to yield trust values that can be used as inputs to the decisionmaking process. The methodology pinpoints which aspects of the providers should be analysed, indicators that decision makers can use to quantify these aspects, and how these quantifications can be aggregated into trust values. We use trust intervals in order to represent trust and we define a summation operator to aggregate trust intervals. The methodology constitutes a guide that analysts and decision makers can follow to evaluate their trust in cloud providers under several dimensions or viewpoints. In the following sections, we examine how trust evaluation in the Cloud has been approached in previous works and we describe the trust-aware methodology that we propose. We also apply the methodology to an eHealth case study and summarize some considerations about the methodology as well as lines for future research. 3.1.1 Trust Evaluation in the Cloud Cloud providers evaluation is a necessary step for cloud sourcing decision-making, but clouds can be evaluated under different angles, including performance (22), scalability (38), accountability (90) and transparency (94). Traditional evaluation has focused on performance and scalability. For example, Bubak et al. (22) provides an evaluation of Infrastructure as a Service (IaaS) cloud 2http://www.infoworld.com/d/security-central/gartner-seven-cloud-computingsecurity-risks-853 3Top Threats to Cloud Computing V1.0,https://cloudsecurityalliance.org/topthreats/ csathreats.v1.0.pdf 49 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC providers. Their focus is on the performance and ratio cost/performance of different providers for scientific computing in the research. Gao et al. (38) define a set of metrics based on calculating the area of polygons, the vertices of which represent measurable performance and scalability indicators of a cloud service. Assessing accountability and transparency is gaining increasing importance. As an example, Nuñez et al. (90) present a metamodel for the assessment of accountability, whereas Pauly (94) proposes a scorecard for evaluating transparency. In a similar direction, Rak and Aversano (103) discuss a framework for building custom benchmark applications that can be used to evaluate performance of different cloud providers. The impact of trust for cloud adoption and some trust-related factors that influence users when selecting cloud providers have been identified in previous works (105)(61). In this direction, Sarwar et al. (9) review several works that elicit relevant trust aspects in the cloud. Ahmad et al. (3) argue that trust in the cloud must be built upon a deep knowledge about the cloud computing paradigm and the provider. In many works, trust depends on the verification of Service Level Agreement (SLA)s (26) or the measurement of QoS attributes (74). Song et al. (121) propose a QoS evaluation model in which key attributes and parameters are defined and quantified. Each attribute is weighted and averaged, yielding a score that can be aggregated with others in the end. These works are usually focused on cloud services evaluation and selection rather than on the cloud providers themselves. Most existing contributions on trust-aware cloud providers evaluation focus on the technical part of the providers. Only a few of them address social aspects, such as the staff or stakeholders of the provider. For example, Pauley (94) creates a scorecard for evaluating transparency of a cloud provider. Its scorecard includes questions that can be answered by 1 (yes) or 0 (no). Transparency is defined as a combination of other attributes, and the questions address these attributes. In the end, the author sums all the scores and divides them by the total possible. Even when this work addresses some security and privacy issues, it does not evaluate threats and does not consider subjectivity or uncertainty during evaluation. Pavlidis et al. (96) propose a process for trustworthy selection of cloud providers. This selection is based on how well the cloud provider fulfils the customer’s security and privacy requirements. It also aims to reduce uncertainty by justifying trust relationships and by making trust assumptions explicit. Compared to our approach, we consider other 50 3.1 Trust-supported Cloud Sourcing Decision in the Planning Phase aspects of the cloud providers and we use trust intervals instead of probabilities and weights. Supriya et al. (72) propose a fuzzy trust model to evaluate cloud service providers that uses the attributes defined by the Service Measurement Index (SMI) (39). Examples of these attributes are assurance, performance and security. Even though uncertainty is embedded in the fuzzy engine, the authors do not provide guidelines on quantifying the attributes or on eliciting cloud knowledge. Qu et al. (102) introduce customers’ feedback in the evaluation, although this evaluation is focused on cloud service selection, rather than on cloud provider selection. Risk as a notion to evaluate cloud services is used by Rödder, Knapper and Martin (111), who propose a set of metrics rather than a methodology. The authors focus on evaluating services offered by the cloud provider, whereas our attention is on the provider as a whole. Metrics weight different attributes and do not include the notion of uncertainty and they do not specify how to retrieve the information required by the metrics, whereas we provide guidelines and a structured knowledge elicitation phase. Habib, Varadharajan and Mühlhäuser (46) propose an evaluation framework that include hard and soft trust concepts, such as direct interaction, indirect interaction and uncertainty. However, they do not propose a concrete methodology, guidelines for trust factors quantification or a systematic domain knowledge elicitation. In a similar direction, Rehman et al. (126) propose a simple framework for monitoring cloud performance based on user feedback, in which the performance of a cloud service is monitored and predicted by these feedbacks. In this direction, Li et al.(66) propose a taxonomy of performance evaluation concepts. The authors argue that performance evaluation works are difficult to understand and compare because they lack consistency and a common terminology. The taxonomy aims to clarify concepts and inaccuratelyused terminology that exist in evaluation works. The same authors suggest that a rigorous methodology for implementing a Cloud evaluation is required, and they propose the Cloud Evaluation Experiment Methodology (CEEM) (64). As a conclusion from our literature review, trust has already been incorporated in the evaluation of clouds. However, in most cases, the purpose of this evaluation is service selection, rather than cloud provider selection. Most contributions are also focused on the metrics rather than on a concrete methodology to gather and quantify all the information. Uncertainty or subjectivity, which are intrinsic to the notion of 51 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC Table 3.4 illustrates some interval summations. Note the last two summations in the table. In the first one, we have complete confidence that the factor value is 0in the first interval and that the factor value is 3in the second one, therefore the aggregation yields a value right in the middle. In the last summation, there is complete confidence in the factor value 3, whereas there is limited confidence in the other value. Therefore the aggregation yields a value closer to 3. Table 3.4: Trust Interval Summations [0,3] + [2,3] [2,3] [1,3] + [2,3] [1.7,3] [2,2.5] + [2.25,2.5] [2.13,2.5] [1,2] + [1,2] [1,2] [0,0] + [3,3] [1.5,1.5] [0,2] + [3,3] [2.25,2.75] In order to present meaningful trust information, we suggest performing three aggregations that correspond to three dimensions or viewpoints: the stakeholders dimension, the threats dimension and the general dimension. Next subsections explain each of them. Stakeholders Dimension This dimension illustrates the level of trust in the cloud provider according to the stakeholders working in it. This aggregation is performed by summing all the intervals of all the factors for each stakeholder, and then summing the resulting intervals for all the stakeholders. Threats Dimension This dimension shows the amount of trust in the cloud provider according to the threats defined by the Cloud Security Alliance (CSA) (see Table 3.3). For each threat, we aggregate the trust intervals of the direct interaction and 3rd party referrals factors. We believe that having independent trust intervals for each threat is convenient, instead of aggregating all the different threats together, because decision makers can make more fine-grained decisions. For example, if the trust interval is low for the threat Data Loss & Leakage, the decision maker can decide not to move the customers data of the organisation to the cloud provider. However, if trust intervals of the other threats for the same cloud provider are high, some services or infrastructures could be outsourced 58 3.1 Trust-supported Cloud Sourcing Decision in the Planning Phase to that cloud provider. If we aggregated all the threats into a unique trust interval, we would lose this valuable information. General Dimension This dimension depicts trust in the cloud provider with regards to the rest of trust factors that are not threats, including Security,Transparency and Accountability. After the trust aggregation step, there are ten trust intervals for a cloud provider: one for the stakeholders dimension, eight for the threats dimension (i.e. one for each threat) and one in the general dimension. 3.1.2.5 Trust Information Visualization The last step consists of plotting the trust intervals for each dimension for comparison purposes and decision making. In the Y-axis, we represent possible trust values, whereas in the X-axis we represent the three dimensions. For each dimension, we draw a line from the lower bound to the upper bound of its trust intervals. This arrangement allows fast comparison between providers in each dimension. Likewise, it allows comparing the trust intervals with the trust thresholds. This is better illustrated in the next section, where we apply the methodology to an eHealth scenario. 3.1.3 Application Example: eHealth In this section we present an application of our methodology to a case study provided by the EU project Network of Excellence on Engineering Secure Future Internet Software Services and Systems (NESSoS)4. The scenario concerns managing Electronic Health Record (EHR)s in clouds. EHRs contain any information created by health care professionals in the context of the care of a patient. Examples are laboratory reports, X-ray images, and data from monitoring equipment. Security concerns in this scenario include: •Confidentiality of EHRs in communication and storage •Data separation of EHRs and other data of the eHealth applications 4The NESSoS project: http://www.nessos-project.eu 59 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC •Authentication mechanism to guarantee confidentiality and integrity •Availability of EHRs •Availability of network connection •Data Origin Authentication Given these security concerns, the CSA threats that become more relevant are the following: Insecure Interfaces and APIs (Threat 2), because these are essential for security functionalities like authentication; Malicious Insiders (Threat 3), because they could steal EHRs and use them for blackmailing or similar criminal activities. Shared Technology (Threat 4) and, specially, Data Loss & Leakage (Threat 5), can lead to a loss of confidentiality of EHRs or data separation. Account or Service Hijacking (Threat 6) leads to bypass authentication controls, including those for data origin authentication; Unknown Risk Profile (Threat 7) and Unknown Causes (Threat 8)5can also have a negative effect on all the security concerns. For the evaluation, we consider the following cloud vendors: Amazon, Apple, Microsoft and Google. We lay stakeholders evaluation aside and we focus on evaluating trust in the threat and general dimensions; retrieving stakeholders information is more difficult but the process and the aggregation would be similar. Next subsections include each step in our methodology. Trust Factor Quantification and Thresholds Definition Threats quantification is based on a data set from CSA, which mapped 11 491 cloud security incidents to these threats6. As explained before, for each trust factor, including the threats, we assign a factor value and a confidence value. For example, in the case of Threat 1 for Amazon, we assigned factor value 0and confidence value 2. The rationale, which must also be included as part of the analysis, is that we found three incidents on record and one that had a significant amount of user accounts affected. As another example, for Security trust 5Note that the original CSA Top Threats are just 7, but the CSA documented cloud security incident referenced numerous incidents that cannot be categorized because of a lack of information. This lead us to adding an additional threat. 6Documented Cloud Security Incidents: https://cloudsecurityalliance.org/download/cloudcomputing-vulnerability-incidents-a-statistical-overview/ 60 3.1 Trust-supported Cloud Sourcing Decision in the Planning Phase factor in Microsoft, we assigned factor value 3and confidence value 2. The rationale is that Microsoft considers some certifications (e.g. ISO 27001) and complies with the CSA control matrix and FedRAMP. Applying Definition 1, we obtain the trust interval [0,1] for the first example, and [2,3] for the second example. Table 3.5 shows the whole quantification for one of the cloud vendors. In parallel and based on the security requirements of the scenario, we define minimum trust values for each trust factor. These thresholds, already aggregated in the threat and general dimensions, are presented in Table 3.6. Trust Aggregation We aggregate the trust intervals of every factor for a given cloud provider. As an example, consider the following: Apple has trust interval [0,2] for Security and [0.33,2.33] for transparency. We use the operator in Definition 3 to aggregate these intervals. The resulting interval is [0.17,2.17]. We would now aggregate this trust interval with the one corresponding to Accountability and Auditing, and so forth, until we reach a final trust interval in the general dimension. The resulting trust interval in the general dimension for each cloud provider is shown in the last column of Table 3.7. We assume that we have no direct previous experience with the providers. Therefore, there is no need to aggregate trust intervals in the threat dimension, which this time only considers information from 3rd party referrals, in this case, from CSA. Trust intervals for each threat and cloud provider are presented in Table 3.7. Trust Visualization Figure 3.2 shows the trust intervals of all cloud providers, whereas Figure 3.3 compares the trust intervals with the trust thresholds. As a conclusion, we see in Figure 3.3 that no cloud provider upholds all trust thresholds. If we focus on data loss and leakage (Threat 5), we see that none of them fully upholds it, but Apple and Amazon seem more interesting under this lens. Microsoft seems to be the best cloud provider according to general properties such as security or transparency, followed by Google. If we focus on the threats in general, we note that again, no cloud provider performs well for all threats. However, according to our analysis, the less bad performers are Microsoft, Apple, Amazon and Google in this order. Summing up, if we were analysts, we would either not pursue any cloud provider for our scenario at this time and repeat the analysis later, or would confront the cloud 61 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC Table 3.5: Trust Factors Quantification for Microsoft Cloud Provider Trust Factor Subtrust factor Factor value Confidence value Rationale Microsoft 3rd Party referral Threat 1 3 2 No incidents on record and there an assumption that the provider invests a lot in controls to prevent those. Microsoft 3rd Party referral Threat 2 1 1 Three incidents on record and one has affected a medium amount user accounts affected (14000). Microsoft 3rd Party referral Threat 3 2 2 One incident on record and other cloud provider do not seem to report incidents at all. Assumption the provider is transparent. Microsoft 3rd Party referral Threat 4 2 1 Two incidents on record and it is assumed they caused limited affects. Microsoft 3rd Party referral Threat 5 1 2 Three incidents on record and it is assumed the cloud provider has problems improving its security controls. Microsoft 3rd Party referral Threat 6 1 2 No incidents on record. No information about security controls for this threat available. Microsoft 3rd Party referral Threat 7 2 2 Once incident on record with only limited effect. Microsoft 3rd Party referral Threat 8 0 2 Eleven incidents reported and the trend seems to increase. This is the largest problem of the provider. Microsoft Security - 3 2 Certifications exist for ISO 27001,SOC,CSA control matrix, FedRAMP. Rumors state that more should follow. Microsoft Transparency - 2 2 We saw texts about identity management and access control on the homepage. Microsoft Accountability - 0 1 We did not find any information about this on the homepage. Microsoft SLA - 2 2 Availability is guaranteed with 99.99%. We could not find rumors about major outages. Microsoft Human Resources Security - 0 1 No information was made public on the homepage and we did not hear rumours. 62 3.1 Trust-supported Cloud Sourcing Decision in the Planning Phase Table 3.6: Trust Thresholds Threat 1 Threat 2 Threat 3 Threat 4 Threat 5 Threat 6 Threat 7 Threat 8 General [1.0,1.0] [0.67,2.67] [0.33,2.33] [2.0,2.0] [2.0,2.0] [0.67,2.67] [0.33,2.33] [0.33,2.33] [0.67,2.67] Table 3.7: Trust Intervals for Cloud Providers Threat 1 Threat 2 Threat 3 Threat 4 Threat 5 Threat 6 Threat 7 Threat 8 General Amazon [0,1] [0.67,1.67] [0,3] [0.33,2.33] [1.33,2.33] [0,3] [0.33,2.33] [0,1] [0.34,1.86] Apple [0.67,1.67] [0,1] [0,0] [0.33,2.33] [1.33,2.33] [0.33,2.33] [0.67,1.67] [0.67,2.67] [0.02, 2.02] Microsoft [2,3] [0.33,2.33] [1.33,2.33] [0.67,2.67] [0.67,1.67] [0.67,1.67] [1.33,2.33] [0,1] [0.8, 2.25] Google [1.33,2.33] [0,1] [0.33,2.33] [1.33,2.33] [0,1] [0.33,2.33] [0.33,2.33] [0,1] [0.53, 2.39] providers with the results and ask for a detailed justifications for their security mechanisms, especially regarding threat 5. 3.1.4 Discussion As discussed in Chapter 2, there are many trust and reputation engines in the literature (56). Given that this methodology is aimed at analysts and decision makers, who do not necessarily have much mathematical background, a requirement for our trust engine was its simplicity. The engine that we present in this work uses trust intervals to represent trust information. There are other engines that are easier to use, such as summation or average engines. However, they present two main problems. First, they usually require weighting the attributes, and selecting weights is difficult and prone to trial-and-error mechanics. Second, they lack the capability to represent uncertainty, which is a concept highly coupled to the notion of trust. We believe that trust intervals present a good trade-off between simplicity and expressiveness. Best practices in risk assessment indicate that practitioners should set an even number of choices since users tend to choose the middle value in odd numbered scales (92). This is why we quantify each trust factor with 4possible values (i.e. from 0to 3). We think that 2would give too few flexibility, whereas more than 4would be confusing. 63 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC Figure 3.2: Comparison of Trust Intervals for the selected Cloud Providers 0.00# 0.20# 0.40# 0.60# 0.80# 1.00# 1.20# 1.40# 1.60# 1.80# 2.00# 2.20# 2.40# 2.60# 2.80# 3.00# AMAZON# APPLE# MICROSOFT# GOOGLE# Threat 1 Threat 2 Threat 3 Threat 4 Threat 5 Threat 6 Threat 7 Threat 8 General A disadvantage of our methodology is that it relies on data that in many cases may not be accessible or available. Cloud providers may be reluctant to provide certain information and it might not be straightforward to gather knowledge about the stakeholders of a cloud provider. Another source of imprecision is subjectivity. By definition, trust is subjective and therefore some of the information that the methodology requires may have a subjectivity bias. The results of the trust evaluation may not be completely accurate, but we advocate that even minimal or partially subjective information is better than blind decision-making. In order to avoid strong subjectivity bias, it is important to state the rationale for each factor quantification. Subjectivity draws a line between trust and trustworthiness. Having a trustworthiness value would help in determining trust. Whereas trust usually depends on subjective 64 3.2 Trust-supported Threats Analysis Figure 3.3: Contrasting Trust Thresholds and Trust Intervals 0.00# 0.20# 0.40# 0.60# 0.80# 1.00# 1.20# 1.40# 1.60# 1.80# 2.00# 2.20# 2.40# 2.60# 2.80# 3.00# Threshold# GOOGLE# 0.00# 0.20# 0.40# 0.60# 0.80# 1.00# 1.20# 1.40# 1.60# 1.80# 2.00# 2.20# 2.40# 2.60# 2.80# 3.00# Threshold# MICROSOFT# 0.00# 0.20# 0.40# 0.60# 0.80# 1.00# 1.20# 1.40# 1.60# 1.80# 2.00# 2.20# 2.40# 2.60# 2.80# 3.00# Threshold# APPLE# 0.00# 0.20# 0.40# 0.60# 0.80# 1.00# 1.20# 1.40# 1.60# 1.80# 2.00# 2.20# 2.40# 2.60# 2.80# 3.00# Threshold# AMAZON# 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 Note that the x-Axsis legend abbreviates Threat 1 to Threat 8 with just the values from 1 to 8. General dimension is value 9 information and may change among trustors, trustworthiness is an objective measure of many different qualities. The ideal situation occurs when trust in a trustee matches the trustworthiness of that trustee (95). This is the reason why we claim that we are evaluating trust and not trustworthiness. 3.2 Trust-supported Threats Analysis As reported by the 2014 CyberSecurity Watch Survey, 28% of cybercrimes were committed by insiders (120), and 46% of the respondents thought that damage caused by insider attacks was more severe than damage from outsider attacks. In fact, insider attacks can cause significant damage to the affected organizations e.g loss of money, loss of reputation, or loss of customers, among others. The CERT Insider Threat Center of the Software Engineering Institute (118) defines an insider as “a current or former employee, contractor, or business partner who has or had authorized access to an organization’s network, system, or data and in65 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC tentionally exceeded or misused that access in a manner that negatively affected the confidentiality, integrity, or availability of the organization’s information or information systems”. Insider attacks are more difficult to detect because they come from trusted employees who have legitimate and often privileged access to critical or valuable assets, and have knowledge of the organization and its processes. The effective defense from insider attacks call for preventive measures that detect and assess the risks associate with insiders, rather than for reactive measures after the attack has been conducted. In this section, we present an approach to assist security engineers in the detection of insider threats during the analysis phase of the system development life cycle. Our approach is complementary to other threats identification approaches that rely on the analyst level of expertise such as risk assessment (70). With our approach, the security engineer can identify automatically the insider threats that exist in a given organization and permission setting and assess the associated risks. The approach consists of first modelling the actors7(i.e. the system stakeholders), their goals, their assets, the security properties (e.g confidentiality, integrity, availability) that stakeholders want to hold for their assets, the permissions that the stakeholders have on assets, and delegation and trust of permissions relationships among them. Trust of permission relationships represent the belief of the grantor of a permission on an asset that the grantee will not misuse it: an actor can be either trusted with a permission or distrusted. The level of trust associated with an agent with respect to a granted permission is crucial to assess the risk of the agent being an insider threat: the lower the level of trust associated with a permission is, the higher is the likelihood that the agent will misuse the permission according to the trustor’s perception. For this modeling, we use the SI* requirements modeling language (77), because it targets socio-technical systems. In order to support the automatic detection of insider threats, we extend the SI* requirements modelling language proposed in (7) with an asset and trust model. The asset model associates assets with a sensitivity value that represent how valuable the asset is for the owner. The trust model extends the native binary SI* trust model (trusted, not trusted) and allows associating different levels of trust (e.g. high, medium 7We use the term actor instead of entity because we are using the nomenclature of SI*. However, according to our conceptual model presented in Section 2.2, an actor is an entity, which can be a trustor or a trustee. 66 3.2 Trust-supported Threats Analysis and low trust) with a permission granted to an agent. Based on the sensitivity and trust levels, we define a set of rules to automatically identify insider threats to an asset and prioritize them based on the risk associated with the threat. The risk associated with the insider threat is given by both the likelihood that the threat occurs and the cost of the permission being misused. The former is quantified by the trust level associated with the permission granted to the insider agent, whereas the latter is quantified by the sensitivity of the asset being harmed. The rest of the section is organized as follows. First, we introduce the SI* framework and its extensions proposed in (7). Next, we present the asset and the trust model followed by the process to identify and prioritize insider threats. Finally, we apply the approach to an eHealth case study of patient monitoring. 3.2.1 The SI* Framework The SI* modeling language (77) has been proposed to capture security and functional requirements of socio-technical systems. SI* is founded on the concepts of agent,role, service, and relations such as And/Or decomposition and means-end. An agent is an active entity with concrete manifestations and is used to model humans as well as software agents and organizations. A role is the abstract characterization of the behaviour of an active entity within some context. An actor is the general way of referring to agents and roles when we do not need to distinguish. The term service is used to denote a goal, a task and a resource. A goal captures a strategic interest that is intended to be fulfilled. A task represents a particular course of actions that produces a desired effect. It can be executed to satisfy a goal. A resource is an artifact produced/consumed by a goal or a task. And/Or decomposition is used to refine a goal, while means-end identifies goals that provide means for achieving another goal or resources produced or consumed by a goal or task. SI* also captures social relationships (e.g., delegation and trust) for defining the entitlements, capabilities and objectives of actors. Originally, a delegation marks a formal passage of responsibility (delegation execution) or authority (delegation permission) from an actor (delegator) to the actor receiving the responsibility/authority (delegatee) to achieve a goal or to provide a resource. Trust in SI* comes in two flavours. Trust of execution represents a relation between two actors representing the expectation of one actor (trustor) about the capabilities of 67 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC Definition 7 (Trust Resolution Function) A trust resolution function is a function, f:S∞ n=2 n z }| { TD × · · · × T D −→ TD, such that f(v1, . . . , vn)≤max(v1, . . . , vn)and f(v1, . . . , vn)≥min(v1, . . . , vn), where vi∈T D and TD is a trust domain. Basically, given a set of trust values, the resolution function produces one unique representative trust value that is upper bounded by the maximum and lower bounded by the minimum of the original trust values. Operators and the resolution function rely on functions to compute the trust values. For this purpose, different functions could be used, like the maximum, minimum, arithmetic or geometric means, etc. Once we obtain the final numeric values for every trust of permission relationship, transformation rules must be used in order to translate these values, which are in an interval [a, b]([0,1] is the chosen one in this case) into a label in a given set of labels that forms a trust scale (2). The next section explains the threat model that we consider in this approach 3.2.4 Threat Model We assume that an agent Ais an insider for a given asset Swhen two conditions hold: a) Ais granted a permission P T on the asset Sthat is sufficient to violate the security property associated with S; b) The agent who owns the resource Sdoes not fully trust Awith permission P T . We consider that the severity of a threat depends on the sensitivity levels of assets and the trust levels on the trust of permissions relationships. We introduce a threat predicate to specify when an agent is an insider for a given instance of an asset and the risk associated with the insider threat. Figure 3.4 is an example of how the risk level of a threat can be determined based on sensitivity and trust levels. The identification of the insider threats and their risk level is based on a set of axioms reported in Table 3.13, where we list the axioms to detect insider threats to assets’ confidentiality, integrity and availability with extreme severity level. The modeling and the reasoning based on the above axioms are supported by the SI* tool which is an Eclipse plug-in equipped with a DLV engine. The tool interface allows to draw an SI* model which is automatically translated into ASP specification. The 74 3.2 Trust-supported Threats Analysis Figure 3.4: Threats Severity Levels The rows of the table represent the trust levels, while the columns represent the sensitivity levels. Each entry of the matrix specifies the severity level for a given combination of sensitivity and trust levels. The severity level can assume one of the following values: Low, Moderate, High, Extreme. How trust and sensitivity relates to each other depends on the organization’s policy and should not be fixed beforehand. Intuitively, the higher the sensitivity of an asset, the higher the damage for the organization. Similarly, the higher the trust level, the lower the likelihood that the agent will misuse the granted permission tool also allows to input the rules for insider threat identification so that the problem of identifying insider threats is the same as checking a DLV program that formalize the SI* model and the axioms. The next section apply the process to an eHealth monitoring scenario. 3.2.5 Application Example: eHealth To illustrate our approach, we use a patient monitoring scenario from the eHealth case study proposed in the NESSoS European project8. The scenario involves five main actors. Patient is monitored by a smart T-shirt which measures medical data (e.g., heartbeat rate, blood pressure, etc.) and transfers them to the Hospital’s computer system. When the patient’s condition is abnormal, the doctor makes a diagnosis and produces a prescription. The patient receives his prescription and requests the drug delivery service to the pharmacy. The Hospital provides medical services to patients. The hospital monitors patients’ health and manages patients’ data, which are stored in the hospital’s computer. When the patient has some problems, the hospital assigns a doctor to diagnose the patient. The Pharmacy is responsible for managing drugs and provide them to the patients. All the information about drugs is stored in the pharmacy’s computer. The Pharmacist works for the pharmacy and is responsible for 8http://www.nessos-project.eu/ 75 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC Table 3.13: Axioms for Identifying Insider Threats Insider Threat to Confidentiality athreat(A1,asset_ instance(service_ instance(S, A, P), A, P) , confidentiality, extreme)←asset_ instance(service_ instance(S, A, P), A, P) ∧ sec_ req_ instance(service_ instance(S, A, P), confidentiality, A, P) ∧ permission_ instance(A1, service_ instance(S, A, P), access) ∧ sensitivity_ instance(service_ instance(S, A, P), very high, A, P) ∧ trust_ perm_ instance(A, A1, asset_ instance(service_ instance(S, A, P), access, very bad)∧A1 6=A bthreat(A1,asset_ instance(service_ instance(S, A, P), A, P) , confidentiality, extreme)←asset_ instance(service_ instance(S, A, P), A, P) ∧ sec_ req_ instance(service_ instance(S, A, P), confidentiality, A, P) ∧ permission_ instance(A1, service_ instance(S, A, P), access) ∧ sensitivity_ instance(service_ instance(S, A, P), very high, A, P) ∧ trust_ perm_ instance(A, A1, asset_ instance(service_ instance(S, A, P), access, bad)∧A1 6=A cthreat(A1,asset_ instance(service_ instance(S, A, P), A, P) , confidentiality, extreme)←asset_ instance(service_ instance(S, A, P), A, P) ∧ sec_ req_ instance(service_ instance(S, A, P), confidentiality, A, P) ∧ permission_ instance(A1, service_ instance(S, A, P), access) ∧ sensitivity_ instance(service_ instance(S, A, P), very high, A, P) ∧ trust_ perm_ instance(A, A1, asset_ instance(service_ instance(S, A, P), access, neutral)∧A1 6=A Axioms T1.a -T1.c identify insider threats to confidentiality: the insider has access permission on the asset being harmed and the owner of the asset places very bad,bad or neutral trust level in the insider for the granted permission. 76 3.2 Trust-supported Threats Analysis providing drugs to be delivered according to the prescription received from the patient. The prescription information is stored in the pharmacy’s computer. Finally, the Drug manager works for the pharmacy and is responsible for managing the drugs. All the drugs’ information is also stored in the pharmacy’s computer. Figure 3.5 shows the SI* model for this scenario. The model consists of five roles: the Hospital, the Patient, the Pharmacy, the Pharmacist, and the Drug Manager. In this particular example, we assume that Patient (Role) can be played by three agents Bob, Kate, and Jane. The Patient (Owns) the resources Patient data and Prescription. It delegates to the Hospital the manage permission on Patient data, and it delegates the access permission on Prescription to the Pharmacy. The Pharmacy has the intention (Request) to fulfill the goal Sell drug which is (AND-decomposed) into subgoals Manage drug and Provide drug: the fulfillment of Manage drug is delegated to the Drug Manager while the fulfillment of Provide drug is delegated to the Pharmacist. The Pharmacy (Owns) the resource PComputer. It grants to Drug Manager the manage permission on PComputer and the access permission on Prescription to the Pharmacist. The Hospital (Role) has an intention (Request) to fulfill the goal Provide medical service which is (AND-decomposed) into subgoals Monitor patient,Manage patient data, and Diagnose. Some goals can produce or consume resources. For example, the goal Diagnose requires the resource Patient data and produces the resource Prescription. The Hospital (Owns) the resource Smart T-shirt and delegates to the Patient the manage permission on it. Table 3.14 depicts a snapshot of the formalization of the model in ASP. Now we proceed to the identification of critical assets. There are three direct assets owned by the Patient role: Prescription,Patient Data, and Monitoring Data. The Patient requires confidentiality to hold for Prescription,availability should hold for Patient Data, while integrity should be satisfied for Monitoring Data.Smart T-Shirt,HComputer, PComputer,Diagnose,Manage Patient data,Monitor Patient, and Provide Drug are indirect assets. For example, PComputer is an indirect asset because the asset Prescription is stored in PComputer and thus the confidentiality of PComputer needs to be preserved. Similarly, the goal Diagnose is an indirect asset because it is linked to the asset Prescription by a means_ end relation, and thus also the confidentiality of the goal needs to hold. Next we determine permissions on assets. This step determines the permissions that roles are granted on assets. The permissions are assigned to roles based on a 77 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC Figure 3.5: Patient Monitoring Scenario in SI* The circles denote roles or agents, the ovals denote goals, while the rectangles represent resources. Dp_a, and Dp_ma represent delegation of permission relation where the permission type is access and manage respectively. Similarly, Tp_a, and Tp_ma represent trust of permission relation where the permission type is access and manage. Services that are considered assets are labeled with the security property that should be satisfied and their sensitivity level. 78 3.2 Trust-supported Threats Analysis Table 3.14: ASP Formalization for SI* Model role(patient) role(hospital) goal(provide_ medical_ service) goal(monitor_ patient) goal(diagnose) .......... resource(monitoring_ data) resource(patient_ data) resource(prescription) resource(computer) resource(smart_ t_ shirt) .......... means_ end(diagnose,prescription) resource(smart_ t_ shirt) del_ perm_ manage(smart_ t_ shirt,patient) del_ perm_ manage(hospital,smart_ t_ shirt) own(hospital,smart_ t_ shirt) del_ perm_ manage(patient_ data,hospital) own(patient,patient_ data) role(pharmacy) .......... own(pharmacy,pcomputer) del_ perm_ manage(pcomputer,drug_ manager) .......... del_ perm_ access(prescription,pharmacy) own(patient,prescription) del_ perm_ access(pharmacy,prescription) .......... agent(kate) agent(bob) play(kate,patient) play(bob,patient) set of axioms that take into account if a role is the owner of a resource and the relations between resources: stored_ in,part_ of and require. The axioms assume the owner of a resource has the highest permission on a resource (i.e., manage) or that a role with the manage permission on a resource can delegate any permission type on the resource to another actor. In addition, if a role has a manage permission on an resource which stores another resource, s/he then has the manage permission also on the stored resource. Last, if a role has a permission on a resource, then s/he has the same permission on each subpart of the resource. For a complete list of the axioms, we refer the reader to (6). In the example, the Patient has delegated the access permission to the Pharmacy on Prescription, and thus the Pharmacy has the access permission on 79 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC Table 3.15: ASP Rules for SI* Model Instantiation Instantiating Assets A1sec_req_instance(service_instance(S, A, P ), SP, A, P)←sec_req(S, SP, P)∧service_instance(S, A, P)∧instance(A, P) A2sensitivity_instance(service_instance(S, A, P ), SL, A, P )←service_instance(S, A, P )∧instance(A, P)∧sensitivity(S, SL, P ) A3asset_instance(service_instance(S, A, P), A, P)←sec_req_instance(service_instance(S, A, P ), SP, A, P)∧ sensitivity_instance(service_instance(S, A, P ), SL, A, P ) Instantiating Permissions A4permission_instance(A, service_instance(S, A, P )←permission(P, S, P T)∧instance(A, P )∧service_instance(S, A, P ) A1states that if a security property holds for a service at organizational level, this property should hold for each instance of that service. A2associates a sensitivity level to an asset instance: the asset instance has the same sensitivity of the asset at organizational level. A3determines if a service instance is an asset: a service instance is an asset if there is a security property that holds for the service instance and the service instance has sensitivity level. A4states that an agent playing a role inherits the permissions that the role is granted on assets. Prescription. Moreover, the Pharmacy has the manage permission on PComputer and thus it has also the manage permission on Drug Info and Prescription that are stored in PComputer. The Pharmacist and the Drug Manager are granted by Pharmacy the manage permission on the PComputer. In addition, the Pharmacist also gains access permission on the Prescription from the Pharmacy. Since the Drug Manager has manage permission on the PComputer and Prescription is stored in PComputer,Drug Manager has manage permission on Prescription. The next step instantiates the SI* organizational model. We only report the axioms to instantiate the elements of the SI* model that are relevant for the insider threat identification. A complete list of the ASP rules to instantiate an SI* model can be found in (141). In the following, we introduce the rules to instantiate assets, agents’ permissions on assets and the trust of permission relations between agents. Instantiate Assets Each instance of an asset is identified with its sensitivity level. The identification is based on the rules given in Table 3.15. In the example Prescription is an asset owned by the role Patient. The Patient role is played by the agents Bob,Kate,Jane, thus each of them owns one of the following instances of Prescription: •asset_ instance(service_ instance(Prescription,Bob,Patient), Bob, Patient), •asset_ instance(service_ instance(Prescription,Kate,Patient), Kate, Patient), •asset_ instance(service_ instance(Prescription,Jane,Patient), Jane, Patient). 80 3.2 Trust-supported Threats Analysis Instantiate Permissions on Assets This step identifies the permissions that agents have on assets. The Pharmacy role delegates the manage permission on PComputer to role Drug Manager. Since the Pharmacy is played by the agent Pharmacy San Raffaele, and the Drug Manager is played by agents Ellen and Mary,Ellen and Mary are granted the manage permission on the instance of PComputer owned by Pharmacy San Raffaele. Instantiate Trust of Permissions relation In this step the trust of permission relationship between agents owning assets and agents having permissions on their assets are identified. This entails determining the level of trust that the owner places in the other agent for the granted permission: the trust value can be already given or it can be computed based on trust paths by the trust model proposed in Section 3.2.3. For example, let us suppose that the agent Bob (playing the Patient role) wants to determine the level of trust with which he can grant the access permission on its asset Prescription to Ellen (playing the Drug Manager role). Since Bob has no direct trust relationship with Ellen we need to evaluate the trust value that Bob places in Ellen based on the following trust chain: trust_ perm_ instance(Bob, Pharmacy Saint Claire, asset_ instance(service_ instance(Prescription,Bob,Patient), Bob, Patient), access, very good) ;trust_ perm_ instance(Pharmacy Saint Claire, Ellen,asset_ instance (service_ instance (Prescription,Bob,Patient), Bob, Patient), access, good). Note that Ellen has access to the instance of Prescription owned by Bob because it is stored in the instance of PComputer owned by Pharmacy Saint Claire on which Ellen has been granted manage permission with good trust level and having the manage implies the access permission. Let us assume that the trust scale and the trust evaluation function are defined as follows: •Very Good →1 •Good →0.8 •Neutral →0.6 •Bad →0.4 •Very Bad →0.2 81 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC This means that values in the range [0,0.2] are assigned the label Very Bad, the range (0.2,0.4] is assigned Bad,(0.4,0.6] maps to Neutral,(0.6,0.8] is considered Good, and (0.8,1] denotes Very Good. Let us also assume that in order to compute the trust value that Bob can place in Ellen for the access permission we use the product as the concatenator operator. Thus, the trust level for Ellen is 1 * 0.8 = 0.8 which corresponds to label Good. Thus, we can add to the SI* model formalization the following trust of permission relationship between Bob and Ellen:trust_ perm_ instance (Bob, Ellen, asset_ instance (service_ instance(Prescription,Bob,Patient), Bob, Patient), access, good). For the example, we are interested in determining all the possible insiders for the instance of Prescription asset owned by the Patient Bob. The reasoning supported by all the previous formalization steps report the following insiders: •threat(Dr Stefano,asset_instance(service_ instance(Prescription, Bob, Patient), Bob, Patient), confidentiality, moderate) •threat(Dr Alex,asset_ instance(service_ instance(Prescription, Bob, Patient), Bob, Patient), confidentiality, moderate) •threat(Ellen,asset_instance(service_ instance(Prescription, Bob, Patient), Bob, Patient), confidentiality, moderate) •threat(Mary,asset_ instance(service_ instance(Prescription, Bob, Patient), Bob, Patient), confidentiality, high) •threat(Ellen,asset_instance(service_ instance(Prescription, Bob, Patient), Bob, Patient), availability, moderate) threat(Mary, asset_ instance(service_ instance (Prescription, Bob, Patient), Bob, Patient), availability, high) Dr Stefano and Dr Alex are two insiders who represent a moderate threat to the confidentiality of Prescription instance owned by Bob because they have been granted access permission on the asset instance and they are trusted good for such permission by Bob. Ellen and Mary are insiders to both the confidentiality and the availability of Prescription asset owned by Bob because the following conditions hold: •the asset instance is stored in the instance of PComputer owned by the Pharmacy Saint Claire and Pharmacy San Raffaele 82 3.2 Trust-supported Threats Analysis •Pharmacy Saint Claire trusts good Ellen with the manage permission on the instance of PComputer owned by the Pharmacy San Raffaele •Pharmacy San Raffaele trusts bad Mary with the manage permission on the instance of PComputer owned by the Pharmacy San Raffaele •Ellen and Mary thus have the same permission on the Prescription asset owned by the Patient Bob stored in the instances of PComputer owned by Pharmacy Saint Claire and Pharmacy San Raffaele respectively •having the manage permission on an asset implies to have also the access permission on an asset •Ellen and Mary are trusted Bob good and bad with the manage permission on the instance of Prescription owned by Bob •manage permission is sufficient to violate the availability of a given asset while the access permission is sufficient to violate the confidentiality of an asset. 3.2.6 Discussion Our framework provides security engineers with a reasoning that automatically produces a list of possible insiders for organizational assets and the risk they may represent to the organization. The reasoning determines if an agent is an insider for an asset and the risk the agent brings about, based on the sensitivity of the asset, the security property specified for it, the permission assigned to the agent on the asset, and the level of trust the asset owner places in the agent for the granted permission. Once the insider threat is identified, further measures can be taken by the organization. There are two scenarios in which using our approach would be beneficial. The first scenario comprises an existing system onto which we want to analyse potential threats, thus following a reactive approach. In this case, we can exploit the existing information about the stakeholders (customers and employees) of the system in order to provide an accurate SI* model, including existing trust relationships. This would yield a set of threats that we can tackle by deploying security solutions on top of the system. In the second scenario, which represents the primary motivation in the context of this thesis, we apply the approach in a proactive manner when the system is in its early 83 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC 11 in 12 13 l e t 14 Trusts : Set ( Dependency ) = Dependency . a l l I n s t a n c e s ( )−>s e l e c t ( 15 16 l e t f i r s t : Set ( Stereotype ) = ge tAppl iedSt ereot ypes ( )−>asSet ( ) 17 in 18 19 f i r s t −>union ( f i r s t −>c l o s u r e ( 20 genera l . oclAsType ( Stereotype ) ) ) 21 . name−>in c l ud e s ( ste re ot yp e ) ) 22 in 23 24 25 −− Get a l l Trust Values 26 27 28 l e t stereotypeMain : St rin g = 29 ’ Trust␣Value ’ 30 in 31 32 l e t 33 TrustValueClasses : Set ( Class ) = 34 35 Class . a l l I n s t a n c e s ( )−>s e l e c t ( 36 l e t f i r s t : Set ( Stereotype ) = 37 getA pplie dSter eotyp es ()−>asSet ( ) 38 in 39 40 f i r s t −>union ( f i r s t −>c l o s u r e ( 41 g en er al . oclAsType ( Stereotype ) ) ) 42 . name−>i ncl u des ( stereotypeMain ) ) 43 in 44 45 −− Get a l l Target Dependencies of t r u s t v a lu es 46 47 l e t stereotypeTargetOne : St ri ng = ’ t r u s t s ’ in 48 49 l e t haveTrustValues : Set ( Dependency ) = TrustValueClasses −>s e l e c t ( 50 clientDependency . tar ge t . getAp plied Stere otype s ( ) 51 . name−>i ncl u des ( stereotypeTargetOne ) ) 52 . clientDependency . t a rg et . oclAsType ( Dependency )−>asSet () 53 in 54 55 56 −− Su btract t r u s t d epe nde ncie s t hat have t r u s t v al ue s 57 58 59 l e t notHaveTrustValues : Set ( Dependency ) = 60 61 Trusts −>−(haveTrustValues ) 62 in 90 3.3 Eliciting and Representing Trust and Reputation Requirements 63 64 notHaveTrustValues−>isEmpty ( ) 3.3.4 Application Example: Smart Grid Table 3.16: OCL Expressions that support Trust-based Security Reasoning and Consistency Checks OCL-EXPR-ID Referenced Class Expression Supporting Analysis Questions Reasoning Support IDHE001 HumanEntity - List all biddable domains that are not a human entity - Are human entities missing? IDEN001 Entity, HumanEntity - List all domains that are not entities or human entities - Are some entities or human entities not elicited yet? IDHE002 HumanEntity - List all human entities that do not have a trusts relation. - Are trust relations of HumenEntities missing? IDEN002 Entity - List all entities that do not have a trusts relation. - Are trust relations of Entities missing? TRTE001 TrustEngine - List all machine domains that have a direct relation to a TrustEngine - Are Trust Engines missing in the model? TRRE001 ReputationEngine - List all TrustEngines that have a direct relation to a ReputationEngine - Are ReputationEngines missing in the model? TRJE001 TrustFactor - Check that the how attribute is set and it is set either to "assigned" or "monitored". - Are all the trust factors either “assigned” or “monitored”? TRCL001 Claims - Check that claims have set the when attribute to either to “after interaction” or “any moment”. - Do all claims specify when they must be provided. TROF001 ObjectiveFactor - List all trust relationships that have no objective factors. - Are all objective factors of the entity considered? TRSF001 SubjectiveFactor - List all trust relationships that have no subjective factors. - Are all subjective factors of the entity considered? Consistency Checks CCRS001 HumanEntity - Check that all HumanEntities have the value trustRole set. - Are HumanEntities modelled correctly ? CCRS002 Entity - Check that all EntitiesEntities have the value trustRole set. - Are Entities modelled correctly ? CCCL001 Claim - Check that all sources of claims are a Human Entity - Are claims modelled correctly ? CCCL002 Claim - Check that all targets of claims are an Entity or Human Entity - Are claims modelled correctly with respect to entities? CCCL003 Claim - Check that all claims have targets and sources - Have claims an origin and a target ? CCSF001 SubjectiveFactor -Have subjective factors the who value set and refer to a trust relationship? - Are trust relationships modelled considered subjective factors ? CCTV001 TrustValue - Check that all dependencies with a trusts relationship have a dependency to a TrustValue - Are trust relationships modelled completely ? CCLTR001 Trustor, Trustee - Check that trust relationships have a trustor and a trustee. - Are all trust relationships modelled correctly? CCLTR002 TrustFactor - Check that All classes with a stereotype trust factor including the inheriting classes subjective and objective factor have a dependency to a trusts relationship or to an entity - Are all trust factors refer to trust relationship or to entities? As an example of our approach, we use the Common Criteria protection profile for the smart metering gateway (21), which defines security requirements for this element. 91 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC The gateway is a part of the smart grid, which is a commodity network that intelligently manages the behaviour and actions of its participants. The commodity consists of electricity, gas, water or heat supply that is distributed via a grid or network. The benefit of this network is envisioned to be a more economic, sustainable and secure supply of commodities. Smart metering systems meter the production or consumption of energy and forward the data to external entities. This data can be used for billing and steering the energy production. We use the trust and reputation extensions of UML4PF introduced in Section 3.3.2 in order to integrate trust and reputation requirements. Likewise, we propose the methodology depicted in Figure 3.7 and we explain and apply each step next. Figure 3.7: Methodology Proposed for Engineering Trust and Reputation Requirements into Systems external input method input/output 1. Establish the Context Roles: Software Engineer, Domain Expert Context Diagram Domain Knowledge Diagrams with relevant trust and reputation information Unstructured System and Environment Description 2. Elicit Trust and Reputation Knowledge Roles: Software Engineer, Trust Engineer, Domain Expert 3. Trust Refinement and Integration Roles: Software Engineer, Trust Engineer 4. Model Reasoning via OCL Role: Software Engineer Refined Domain Knowledge Diagrams, Problem Diagrams that contain elicited security requirements and computation engines Consistent and evaluated diagrams with regard to trust and reputation Trust and Reputation Information OCL Expressions for Model Consistency Step 1: Establish the Context Trust relationships are only valid for a specific context. The software engineer and the domain expert describe the context of the software development in a context diagram. This diagram describes the machine in its environment using domains and interfaces between them. A set of textual functional requirements refers to the domains in the context diagram. Afterwards, the trust engineer11 elicits assets and security requirements for them. 11We use the term trust engineer to refer to both a security engineer and an expert in trust models. In some cases, these profiles may be covered by the same person. In others though, two different persons with more specialized profiles may be required. 92 3.3 Eliciting and Representing Trust and Reputation Requirements Figure 3.8 shows the context diagram that describes the machine to be built in its environment. The Machine is the SmartMeteringGateway, which serves as a bridge between the Wide Area Network wan and the Home Area Network han of the Consumer. The Meter is connected to the machine via a Local Metrological Network lmn. This is an in-house equipment that can be used for energy management. The Controllable Local System (CLS) is a device located in the consumer house and which is connected to the smart grid system; therefore, the energy of the CLS can be controlled by the system. Some examples include the heater, the oven or the lights over an area of the house. As for requirements, the Meter sends meter data to the SmartMeteringGateway, which can store this data. The Meter can also receive updates from the AuthorizedExternalEntity forwarded via the SmartMeteringGateway. The AuthorizedExternalEntity receives meter data in fixed intervals from the SmartMeteringGateway. The Consumer can retrieve meter data from the SmartMeteringGateway. The Consumer can also configure the SmartMeteringGateway, send commands to the CLS, receive status messages from the SmartMeteringGateway and store user data in it. Figure 3.8: Context Diagram for the Smart Metering Gateway <<Machine>> SmartMeteringGateway <<BiddableDomain>> AuthorizedExternalEntity <<causalDomain>> Meter <<causalDomain>> CLS <<BiddableDomain>> Consumer 1 <<han>> IF_GW_U <<lmn>> IF_GW_M <<wan>> IF_GW_WAN <<han>> IF_GW_CLS Step 2: Elicit Trust and Reputation Knowledge The domain expert and the trust engineer have to work together. The former elicits trust-unaware domain knowledge diagrams, whereas the latter (together with the former) provides an initial trust domain knowledge, where the high level aspects of the trust and reputation models are first sketched. These aspects include specifying trust entities, their trust relationships, claims, and trust factors. 93 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC Once the context is established, trust and reputation information must be elicited. We show in Figure 3.9 a domain knowledge diagram focusing on the main elements of one trust relationship between the HumanEntity Consumer and the Entity CLS. The trust relationship has a TrustValue and there is a SubjectiveFactor associated to the Consumer. On the other hand, Figure 3.10 shows relevant information for reputation purposes. Concretely, we are specifying which entities can make Claims about others, and which objective factors are considered to yield those claims. In this example, a HumanEntity AuthorizedExternalEntity can make Claims about the Entity CLS, and the ObjectiveFactor UnplannedReparis refers to the CLS. Figure 3.9: Domain Knowledge Diagram - Analysing the Trust Relationship ConsumerCLS <<Entity>> CLS <<HumanEntity>> Consumer <<SubjectiveFactor>> ExplicitTrust <<refersTo>> <<trusts>> <<TrustValue>> Consumer-CLS-Trustvaule <<refersTo>> Figure 3.10: Domain Knowledge Diagram - Analysing Reputation Information <<Entity>> CLS <<BiddableDomain,HumanEntity>> AuthorizedExternalEntity <<Claim>> AuthorizedExternalEntity-CLS <<source>> <<target>> <<ObjectiveFactor>> UnplannedRepairs <<refersTo>> Step 3: Trust Refinement and Integration The information in the trust domain knowledge diagrams is refined in this step by the software and trust engineers. The final diagrams contain detailed information about trust and reputation relationship, e.g. roles played by the entities, insight on the claims, the trust values, and objective and subjective factors. Figure 3.11 shows the refinement of the previous domain knowledge diagrams. The Consumer plays a trustor role in the Consumer-CLS-Trust relationship, it uses the subjective factor ExplicitTrust for this relationship and his trust disposition is neu94 3.3 Eliciting and Representing Trust and Reputation Requirements tral12. The ExplicitTrust subjective factor has 3as initial value and is assigned by the Consumer. The Consumer-CLS-Trustvalue is a unidimensional continuous value between 0and 5, with threshold value 3. This latter value refers to the threshold over which we assume that a trustor trusts a trustee. The CLS plays a trustee role in the Consumer-CLS-Trust relationship, although it also plays the target role with regard to the AuthorizedExternalEntity-CLS claim. It presents an objective factor, UnplannedRepairs, which is monitored (in contrast to manually assigned). The AuthorizedExternalEntity plays a source role because it can make claims about the CLS after an interaction with it. Claims are about the past behaviour of the target, and are represented by a unidimensional discrete number between 0and 10. In addition to refining trust and reputation information, the trust engineer and the software engineer collaborate to analyse how the respective trust and reputation engines integrate into the system-to-be and their relationship with the system requirements and the machine. Figure 3.12 depicts the interactions between the three ma12We consider that for this scenario, a neutral trust disposition is reasonable, whereas other scenarios might require assuming that trust dispositions are lower or higher. Figure 3.11: Domain Knowledge Diagram - Refinement of Trust and Reputation Information <<BiddableDomain,HumanEntity>> AuthorizedExternalEntity <<Claim>> AuthorizedExternalEntity-CLS about: past behaviour scale: 0..10 format: discrete dimension: 1 when: after interaction <<source>> <<target>> <<ObjectiveFactor>> UnplannedRepairs description: It refers the amount of unscheduled maintenance activities and bug fixes of the CLS how: monitored <<refersTo>> trustRole: Source <<Entity>> CLS <<HumanEntity>> Consumer <<SubjectiveFactor>> ExplicitTrust <<refersTo>> <<trusts>> Consumer-CLS-Trust <<TrustValue>> Consumer-CLS-Trustvalue <<refersTo>> trustRole: Trustor subFactor: ExplicitTrust trustDisposition: neutral value: 3 how: assigned who: Consumer format: continuous scale: 0…5 value: 3 dimension: 1 trustRole: Trustee, target objFactor: UnplannedRepairs 95 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC chines of the system: the SmartMeeteringGateway, the CLS-TrustEngine and the CLSReputationEngine. Both computation engines yield continuous values. The trust engine can retrieve reputation values from the reputation engine in order to compute trust values13. The SmartMeeteringGateway can retrieve trust information and act accordingly. Figure 3.12: Problem Diagram - Describing Trust and Reputation Engines <<Machine,Entity>> SmartMeteringGateway <<causalDomain,Entity>> CLS <<BiddableDomain,HumanEntity>> Consumer <<Machine,TrustEngine>> CLS-TrustEngine engineType: continuous description: "The engine calculates a trust value for CLS." <<Machine,ReputationEngine>> CLS-ReputationEngine engineType: continuous description: "The engine calculates a reputation value for CLS." <<securityRequirement>> Preventing Data Leackage <<considers>> <<Requirement>> R1 <<complements>> <<constrains>> <<BiddableDomain,HumanEntity>> AuthorizedExternalEntity <<considers>> CLS-TE!{getReputationValue} CLS-TE!{sendTrustValue} SMG!{sendCLSWarning} We consider the following functional requirement of the smart metering gateway in our example: R1 The CLS can receive energy consumption data from the Meter. We elicit the security requirement Prevent Data Leakage that complements the functional requirement R1. If the value of the Consumer-CLS-Trustvalue, which is computed by the trust engine, is above the minimum trust threshold (initially set to 3), no action shall be taken. Otherwise, communications with the CLS should be blocked by the SmartMeeteringGateway. In addition, the claims issued by the AuthorizedExternalEntity (i.e. AuthorizedExternalEntity-CLS) are used by the reputation engine to yield a reputation value, which is fed into the trust engine. Both the trust events and the consequences of trust decisions can be sketched by means of dynamic diagrams, as depicted in the example in Figure 3.13. Step 4: Model Reasoning via OCL We use the OCL expressions in Table 3.16 in this step. In particular, we illustrate the expression CCCL001 in detail in the following. 13This is the traditional way of relating trust and reputation: reputation is a valuable source of information for trust computation. 96 3.3 Eliciting and Representing Trust and Reputation Requirements Figure 3.13: Sequence Diagram - Describing Trust and Reputation Events <<CausalDomain, Entity> CLS <<Machine, Entity> SmMeetGateway <<Machine, RepEngine>> CLS-ReputationEngine <<Machine, TrustEngine>> CLS-TrustEngine <<TrustInfo>> Consumer-CLS <<ReputationInfo>> CLS Reputation Block CLS communication Weekly Checking <<BiddableDomain, HumanEntity> AuthorizedExEntity Claim (Negative) Bad response Claim Update reputation New reputation value Update trust New trust value (below threshold) Everything starts with the AuthorizedExternalEntity performing a weekly check on an CLS. After such interaction (which we assume is negative), the AuthorizedExternalEntity issues a negative claim, which is forwarded by the SmartMeeteringGateway to the ReputationEngine, which uses this claim to recompute a new reputation value. This new reputation value is sent to the TrustEngine, which recalculates the trust value between the Consumer and the CLS, and this new trust value (together with some other information such as the the threshold of the relationship) is sent back to the SmartMeeteringGateway. As a result of the new trust value being lower than the threshold, the SmartMeeteringGateway blocks the communication with the CLS, because the Consumer no longer trusts the CLS. The expression shown in Listing 3.3 collects all classes with the stereotype Claim (lines 1-8) and all dependencies with the stereotype source (lines 9-15). The expression filters the dependencies that start at a class with the stereotype Claim and end at a class with the stereotype HumanEntity (lines 16-21). Finally, the expression subtracts the classes with the stereotype Claim that are at the end of the previously mentioned dependencies from all classes with the stereotype Claim (lines 22-24). In our case all the claims originate from the human entities and the expression returns an empty set. Otherwise we would get a list of classes for analysis. Listing 3.3: CCL001. List all sources of claims that are not a Human Entity 1 l e t stereotypeMain : Str ing = ’ Claim ’ in 2 l e t 3 cl aimCl asses : Set ( Class ) = 4 Class . a l l I n s t a n c e s ( )−>s e l e c t ( 5 l e t f i r s t : Set ( Stereotype ) = getApplie dSter eotyp es ( )−>asSet () in 6 f i r s t −>union ( f i r s t −>c l o s u r e ( g en er a l . oclAsType ( 7 Stereotype ) ) ) . name−>in c l ud e s ( stereotypeMain ) ) 97 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC 8 in 9 l e t s ter eot yp e : S tring = ’ source ’ in 10 l e t 11 Sources : Set ( Dependency ) = Dependency . a l l I n s t a n c e s ( )−>s e l e c t ( 12 l e t f i r s t : Set ( Stereotype ) = ge tAppl iedSt ereot ypes ( )−>asSet () in 13 f i r s t −>union ( f i r s t −>c l o s u r e ( g en er al . oclAsType ( 14 Stereotype ) ) ) . name−>i n c lu d es ( st er eo typ e ) ) 15 in 16 l e t st ere otypeSo urc e : St ring = ’ Claim ’ in 17 l e t stere otype Targe t : S tring = ’Human␣ Entity ’ in 18 l e t 19 DependencyClaims : Set ( Dependency ) = 20 Sources−>s e l e c t ( source . get Appli edSte reoty pes () . name −>i n cl u des ( ste reo typeSource ) and ta rg et . getA pplie dSter eotyp es ( ) . name −>i n clu d es ( ster eotypeTarget ) ) 21 in 22 l e t corre ctCla ims : Set ( Class ) = 23 DependencyClaims . source . oclAsType ( Class )−>asSet ( ) in 24 cl aimClas ses −cor rectC laims We illustrate our tool support in Figure 3.14, which shows the modelling of a UML4PF trust model. Figure 3.15 depicts an OCL expression executed on that model and its results. 3.3.5 Discussion The proposed methodology uses an extension over the problem frames notation in order to accommodate trust and reputation concepts and relationships among these concepts. Intensive context-awareness is an envisioned property of future, complex software systems, and problem frames fit well due to their focus on describing the context around the system-to-be. Also, the context becomes of paramount importance when analysing trust relationships and reputation information, because most of the valuable sources of information for computing trust and reputation will come from this context. We discussed the approach with the security practitioners in the ClouDAT project14 in a brainstorming session. We presented the methodology to practitioners in the field of security engineering that were familiar with the Protection Profile. As a result, we found that our methodology helped the practitioners distinguish between the concepts of trust and reputation. The practitioners mentioned that this structured procedure helps identify trust relationships, supports the identification of reputation claims, helps not forget relevant 14http://ti.uni-due.de/ti/clouddat/en/ 98 3.3 Eliciting and Representing Trust and Reputation Requirements entities and their attributes, and supports the creation of consistent trust and reputation diagrams. However, the following concerns towards our methodology were raised: •The results of the OCL reasoning expression might lead engineers to add random elements to achieve completeness. •Reading the output of all expressions might be too time consuming. •The UML profile and the methodology have to be learned beforehand. •Our method does not integrate into common security development life cycles such as the Microsoft SDL15. The outcome of our methodology is a set of requirement artifacts that represent functional requirements and trust concerns of the system. Given that these artifacts are shaped around the problem frames approach, and that this approach encourages the modularization of the system into domains, the artifacts provide a good starting point for sketching the architecture of the system. In our methodology, trust and reputation models are decomposed in their constituent elements, which provide developers with sufficient information to implement the models and to integrate them into the system in the next stages of the development life cycle. 15Microsoft Security Lifecycle http://www.microsoft.com/security/sdl/default.aspx. 99 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC wear a device capable of measuring vital signs (e.g. blood pressure). This device must be able to send this information to other systems that will show it to physicians for monitoring purposes. The goal is to build a web application through which the physician and the patient can interact in a trusted way17. In this application, the physician can add and remove a wearable device to the system, start the process to assign the device to a patient, configure both critical and uncritical alerts, ask patient consent to use his data for research purposes, create an advice for the patient based on the patient’s data, demand an immediate reading from the wearable and start the process to change a patient’s wearable. Patients can configure uncritical alerts, ask for second opinions (to other physicians), accept or deny consent about their data being used for research, read the physician’s advices, complete the device assignment process started by the physician and demand a physician change. These requirements are represented by the use cases illustrated in Figure 3.16. Figure 3.16: Use Case Diagram Patient Physician Add Weareable to System Remove Wearable From System Configure Uncritical Alerts Configure Critical Alerts Ask Patient Consent Create Advice Assign Device to Patient 1 Demand Immediate Read Ask for Urgent new Wearable Ask for Second Opinion Ack/Deny Consent See Recent Advices Assign Device to Patient 2 Ask for Doctor Change Ensuring security in this scenario is very important. On the one hand, it is required to ensure that data of one patient do not appear in the EHRs of other patients. Confidentiality and integrity of the data, as well as integrity of the wearable is also required. 17As discussed in Section 1.1.3, we assume that basic security mechanisms (e.g. TLS/SSL for Internet communications) are underpinning the trust and reputation solutions that we will develop. 106 3.4 Designing Trust and Reputation Solutions Yet even though there are important hard security requirements, the system must also be trust-aware, in the sense that physicians and patients must trust the information provided by each other. A possible trust-aware use case diagram is shown in Figure 3.17. We state that there is a trust relationship between the patient and the physician. The patient plays atrustor role and the physician plays a trustee role. In addition, there is a trusts connector, which is adorned by the context where this trust relationship is set, namely monitoring. There is another trust relationship between the physician (who therefore also plays a trustor role) and the wearable. The patient also plays the source role and can therefore make claims (claims connector) about the physician, who plays in this case the target role. Figure 3.17: Trust-aware Use Case Diagram <<trustor>> <<source>> Patient <<trustee>> <<trustor>> <<target>> Physician Add Weareable to System Remove Wearable From System Configure Uncritical Alerts Configure Critical Alerts Ask Patient Consent Create Advice Assign Device to Patient 1 Demand Immediate Read Ask for Urgent new Wearable Ask for Second Opinion Ack/Deny Consent See Recent Advices Assign Device to Patient 2 Ask for Doctor Change <<trustee>> Wearable <<trusts>> <<trusts>> <<claims>> <<decides>> <<decides>> <<decides>> <<decides>> <<decides>> <<decisionCriteria>> reputation <<trustContext>> monitoring Up to now, we have defined the main entities, the trust roles they can play, and the trust relationships and possible claims that the application considers. We also need to include for which purpose this information is going to be used, and this is the role of the decides connector. The patient may decide to ask another physician for second opinion. In order to decide who this other physician is, he uses reputation information about the physician (annotation decision criteria). Also, the physician may ask for a 107 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC new wearable if his trust in the actual wearable falls below a certain threshold. Thus, we are using trust and reputation to help entities make decisions at runtime. Claims and trust relationships can be further refined in trust-aware class diagrams, as shown in Figure 3.18, 3.19 and 3.20. Regarding the patient-physician relationship, we specify the context of this relationship, which should be consistent with the context in the use case diagram, the dimension and format, which are 1and numeric in this case, the scale, which is the interval [0,1], and the default value, which is 0.5. Thus, every trust relationship between a patient and a physician could be assigned by default (i.e. during bootstrapping) the value 0.5and could take values between 0and 1over the system life. Also, we specify some information regarding the trustor and the trustee. In this relationship, the trustor is a human entity and has a subjective factor that influences the trust relationship: capability belief. This means that the belief that the patient has in the capability of the physician must be considered when assessing the trust relationship, as stated also by the trust engine that updates the trust relationship. This engine uses a continuous engine, meaning that it will yield a continuous value by aggregating continuous factors. The list of factors used by the engine are the reputation of the trustee, the belief of the trustor, and the trustor’s quality feedback. In this quality feedback, illustrated in Figure 3.20, there is a reputation engine which provides target entities with reputation scores. The reputation engine gathers the claims that different patients make about a given physician and computes a final reputation using an average, which should be displayed by a 3 stars notation. In addition to the claims, time is also used to derive this reputation score. Figure 3.18: Patient-Physician relationship <<trustor>> Patient {type = human, subFactor = capability} <<trustee>> Physician {type = human} <<trustRelationship>> PatientMonitoring {context = monitoring, dimension = 1, format = quantitative, scale = [0,1], default = 0.5} <<trustEngine>> PatientPhysicianEngine {engine = continuous, factors = (reputation,capability belief, trustor's qualityFeedback)} <<computesTrust>> <<Factor>> Capability Belief {attribute = capability, scale = [0,1], source = patient, how = assigned} <<uses>> 108 3.4 Designing Trust and Reputation Solutions Figure 3.19: Data Retrieval Trust Relationship <<trustor>> Physician {type = human} <<trustee>> Wearable {type = system, objFactor = reliability} <<trustRelationship>> DataRetrieval {context = monitoring, dimension = 1, format = quantitative, scale = [0,10], default = 5} <<trustEngine>> PatientPhysicianEngine {engine = discrete, factors = trustee's reliability} <<computesTrust>> <<Factor>> Wearable Reliability {attribute = (reliability, precision), scale = [0,5], source = physician, how = monitored} <<uses>> Figure 3.20: Quality Feedback Claim <<source>> Patient {type = human} <<target>> Physician {type = human} <<claim>> qualityFeedback {context = monitoring, dimension = simple format = qualitative, scale = (bad,good)} <<reputationEngine>> PatientPhysicianEngine {engine = average, factors= (qualityFeedback, time), display = 3 stars} <<computesReputation>> For every factor defined in the engine, we can define a new Factor stereotype and specify some of the important properties of them. Figure 3.18 shows that capability belief, assigned by the patient, should take a value in the interval [0,1] and should capture the attribute trustor’s capability belief. Figure 3.19 illustrates the wearable reliability factor, which measures the reliability and precision of the wearable in a scale of [0,5], being the physician the one that triggers a system that monitors the factor. Note that from the class diagrams information, especially after identifying the factors that we need, we can go back to the use case diagram during the second iteration and add new information as needed. The patient should have means of rating a physician and to set the physician preferences. This last use case captures the capability belief, as the preference list will likely be made by the patient in terms of this capability belief about the physicians. The physician should be able to measure the wearable reliability and update this factor, therefore he also should play the role factor producer. These 109 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC changes are depicted in Figure 3.21. Figure 3.21: Trust-aware Use Case Diagram (2nd Iteration) <<trustor>> <<source>> Patient <<trustee>> <<trustor>> <<target>> <<factorProducer> Physician Add Weareable to System Remove Wearable From System Configure Uncritical Alerts Configure Critical Alerts Ask Patient Consent Create Advice Assign Device to Patient Demand Immediate Read Ask for Urgent new Wearable Ask for Second Opinion Ack/Deny Consent See Recent Advices Ask for Doctor Change <<trustee>> Wearable <<trusts>> <<trusts>> <<claimsAbout>> <<decides>> <<decides>> <<decides>> <<decides>> <<decides>> <<decisionCriteria>> reputation Rate Physician Set Physician Preferences Measure Wearable Reliability <<trustContext>> monitoring How the business and trust layers of the application interact may be a valuable information for designers. This can be depicted by a behavioural diagram, such as an activity diagram. The goal is to represent which actor can trigger a trust event and how, and what are the consequences of that trust event. We propose using swim lanes in order to separate the responsibilities of actors, the business logic and the trust logic in the whole application. Figure 3.22 shows the trust event triggered as a consequence of the patient changing its preference list of physicians, whereas Figure 3.23 depicts the trust event triggered when the patient asks for a second opinion. The basic deployment for this application, without considering trust information, consists of a sensor that communicates with a wearable, which in turn, aggregates the information and sends it to a front-end server running the application. This front-end server will send the information to a back-end server that will store it into the patient’s EHR and that executes a configuration application only available to administrators. Figure 3.24 shows a trust-aware deployment diagram. The wearable device can decide, based on the front-end server reputation, to which server to send information. The same happens between the front-end server and the back-end server. Of course we are 110 3.4 Designing Trust and Reputation Solutions Figure 3.22: Activity Diagram for Use Case Set Physician Preferences Patient Business Layer Trust Layer Change'physician' order' Store'new'order' Update' capability'belief' Update'trust' rela8onship' <<localPreCondition>> {New order is different from current order} <<localPostCondition>> {Trust Relationship is updated using the PatientPhysicianEngine} Figure 3.23: Activity Diagram for Use Case Ask for Second Opinion Patient Business Layer Trust Layer See#list#of# physicians# Retrieve#list#of# physicians# Retrieve# physicians’# reputa5on# Show#list#of# physicians# Choose#physician# <<localPostCondition>> {The list is ordered by physician's reputation} assuming that the final deployment will consist of, at least, two front-end servers and two back-end servers. Otherwise, a decision is not possible. We can also make explicit on which node the reputation values for different entities in the system will be stored (i.e. assuming a centralized reputation model). In this case, a node is reserved to play the role of a reputation server that will store the reputation values for physicians, the front-end servers and back-end servers. 111 3. INCORPORATING TRUST ENGINEERING IN EARLY PHASES OF THE SDLC Figure 3.24: Trust-aware Deployment Diagram <<device>> FrontEndServer <<device>> BackEndServer <<device>> Wearable <<device>> Sensor Configuration Server Database Application Server <<ReputationManager>> Reputation Server {entities=(physician, FrontEndServer,BackEndServer)} <<decides>> <<decides>> <<decisionCriteria>> reputation 3.4.5 Discussion Our goal with this work has been to bridge the gap that prevents trust from being properly addressed during the initial phases of the SDLC. Nonetheless more work still remains to be done. First, the profile should be further extended in order to represent policies, credentials and trusted third parties, which constitute key concepts of many trust management systems nowadays, as explained in Section 2.1.2. The profile should also allow representing how trust information can be propagated between entities in the system. Trust derivation from lower software abstractions (e.g. trust among components) to higher level abstractions (e.g. trust among processing nodes), if possible at all, is an interesting field that requires much further exploration. Finally, there is a need for defining the semantics and constraints of each syntactic element. Tool support is then required to check compliance with these constraints and to derive design patterns and code from the specification. In this direction, how to integrate our approach with existing frameworks (e.g. UMLsec) should be analysed. 112 Chapter 4 Enabling Trust and Reputation during Implementation This chapter describes the requirements, the architecture and some implementation guidelines of a trust and reputation development framework that allows software developers to implement a wide range of trust and reputation models. The framework builds upon the concepts introduced in Chapter 2, and its goal is supporting the design and development of trust and reputation models specified by means of the tools explained in Chapter 3. The focus of this framework is on evaluation models (see Chapter 2), and therefore decision models are laid aside. From a high-level point of view, the framework is a middle-tier server that mediates between the client application and the database tiers, as depicted in Figure 4.1. The application requests trust and reputation information from the databases, and requests updates on new trust and reputation information as a response of some events signalling. The kind of Application Programming Interface (API) that the framework exposes depends on the implementation details, and could range from remote procedure calls to a RESTor SOAP-based API. Even though we do not provide a concrete implementation, some implementation guidelines are outlined. The chapter is organized as follows. Section 4.1 discusses the high-level requirements that the framework must meet. Section 4.2 presents a high-level architecture of the framework, which is refined into a low-level architecture in Section 4.3. Hints towards the implementation of the framework are provided in Section 4.4, and a social cloud application example is presented in Section 4.5. Finally, Section 4.6 discusses some 113 4. ENABLING TRUST AND REPUTATION DURING IMPLEMENTATION Figure 4.1: The Framework in Context Developer Application Trust Framework update retrieve design and implementation aspects of the framework, as well as some challenges and lines for future research. 4.1 Framework Requirements This section summarizes the requirements that the framework must meet. The framework has to support the implementation of evaluation models. Pure evaluation models establish trust relationships between entities, and their main goal is to compute trust values for these relationships and to help entities decide whether to collaborate or not with each other. Propagation models also build on trust relationships, and their primary goal is to disseminate existing trust information in order to derive new trust relationships. Reputation models compute reputation scores for entities, which must be stored ( either centrally or distributively) and entities should be able to access this information when required. The following list of requirements describes the coarse-grained functionality with which the framework should provide developers: •Entities management: entities hold trust values in other entities. The framework must be able to give a unique identifier to each entity in the system and to retrieve trust and/or reputation information from an entity. •Trust relationships management: trust relationships might change over time. New trust relationships might be created (e.g. by propagation models), other relationships might be deleted, and trust values attached to these relationships may change. Trust relationships can be affected by reputation, but also by objective and subjective factors of trustors and trustees. 114 4.2 High-Level Architecture •Computation engines definition: computation engines are in charge of computing a trust or reputation score, depending on the model. Although the framework can provide some default built-in metrics implementations, it is important to let developers define their own trust metrics, as they are the core concept in evaluation models. •Events definition: events that occur in the system trigger the communication with the framework. It is required to configure the framework to respond to these events accordingly. •Claim management: the type and value of a claim may determine a reputation score. It should be possible to configure claims in order to support applicationspecific needs. •Factors management: a trust metric comprises objective and subjective factors. It is important to let developers create new factors, which can be used by userdefined metrics. •Trust dissemination: trust information can be propagated by means of operators along trust chains. Developers should be empowered to define their own operators, or to use some built-in ones. •Time and uncertainty: these factors may play an important role when computing a trust or reputation score. The framework should provide the developer with mechanisms to include them as part of the computation process. •Trust and reputation separation: the framework should allow developers to consider trust and reputation as different concepts. However, given their strong relationship, it should be possible to take each other into consideration when computing a trust/reputation score. 4.2 High-Level Architecture A high-level architecture of the framework is depicted in Figure 4.2. This architecture bridges a gap between the conceptual model presented in Chapter 2 and the low-level architecture and implementation that will be discussed in Sections 4.3 and 4.4. Its goal 115 4. ENABLING TRUST AND REPUTATION DURING IMPLEMENTATION Figure 4.7: Data Manager Component Trust Statement Reader API Translator uses read trust statement database connector configure data store get trust information DATA MANAGER Entity Reputation Statement Trust Statement uses Trust Relationship 4.3.2 Data Structures Even though more modules and structures might arise in a further detailed design, there are four data structures that are specially relevant as they encapsulate crucial information that flow between components. If we consider them from an Object-Oriented (OO) perspective, they could be refined as classes, which are shown in Figure 4.8. For each of these structures, only the most important attributes and applicable functions (i.e. methods in OO design) are shown. The Event structure represents an event by means of a name, a context, a source of the event, and a target of the event. Several event types can be pre-defined, but new events can be created. AClaim represents the assessment made by an entity. The type of event that is triggered determines the type of claim that is made. A claim has a scale (minimum and/or maximum boundaries) and a value, which might be numeric or qualitative. A claim can be normalized (resp. denormalized) from its range scale (resp. interval [0,1]) to the interval [0,1] (resp. its range scale). A trust metric comprises a set of subjective and objective Factors. Two typical subjective factors are introduced in the next section, but there might be more factors that the trust metric may require. A factor is identified by a name, a value, a source entity and a target entity. In some situations a factor may represent a property or aspect of an entity that is independent of any other entity (e.g. an objective factor about an entity, such as the number of transactions that the entity has completed), and therefore the factor will only have a target entity. AReputation Statement, as stated previously, contains a source, a claim and a target. Source and target are entities. In order to allow developers to take time into 122 4.3 Low-Level Architecture account, a reputation statement holds a time stamp, which indicates when the reputation statement was made. Also, as a reputation statement is made in a context, the latter is considered as part of the statement. ATrust Statement (which is a new notion that has not been mentioned previously) contains a reputation statement, a reputation value and a trust value. This structure allows the framework to convey trust and reputation information separately, fostering the idea that trust and reputation are two different concepts. A trust statement is the structure that is passed onto the data manager in order to update the different database tables. ATrust Relationship represents the trust value that a trustor (the source Entity) places on a trustee (the target Entity). As in the case of reputation statements, trust relationships need to consider time and the context under which they make sense. An Entity represents any object that can be evaluated. It has a unique name, a type (Human, Non-Human and Reputation Statement), a reputation score and the context under which the reputation score is assigned. A HumanEntity is an entity which, additionally to the previous fields, also holds a rating bias and a list of beliefs, which can be actually represented by factors. Figure 4.8: Important Data Structures name: String context: String source: String target: String Event isNormalizable(): Boolean normalize(): float denormalize(float): ClaimValue name: String scale: Scale value: ClaimValue Claim rs: ReputationStatement rep: RepValue trust: TrValue Trust Statement source: Entity target: Entity claim: Claim context: String timestamp: Time Reputation Statement trustor: Entity trustee: Entity trust: Claim context: String timestamp: Time Trust Relationship name: String type: EntityType repScore: RepValue context: String trs: List<TrustRelationship> Entity ratingBias: float beliefs: List<Factor> Human Entity context: String name: String value: FactorValue source: Entity target: Entity Factor 123 4. ENABLING TRUST AND REPUTATION DURING IMPLEMENTATION 4.3.3 Incorporating Trustor’s Subjective Factors When an entity rates another entity, their trust relationship may change. As explained in Chapter 2, there are other factors that influence trust beyond reputation, such as the trustor’s subjective properties. The framework provides developers with support to include the following properties: •Rating bias: this property indicates the usual disposition of an entity to high or low ratings. If the entity has always rated others with the maximum value in the past, the fact that now the same entity rates a new entity with a high value does not give much information. However, it would give a lot of information if the entity rated another entity with a low value. There are different ways to provide built-in support for this. One way is by using standard deviation of all the claims made by the entity over a period of time. •Beliefs: they indicate how much an entity believes in the capability, honesty, etc. of a target entity. This information could be directly assigned by the entity, or it could be derived automatically from several events depending on the context. In a social network application, for example, the number of visits to the target’s profile or the ratings given to other entities’ claims could provide insightful information for determining beliefs among entities. Beliefs can be represented as factors data structures (see previous section) where the source entity holds the belief about the target entity. The next section provides further details on possible implementation options. 4.4 Implementation Guidelines The framework can be deployed as a JavaEE1application that constitutes a runtime platform onto which to develop trust-aware applications. The hint of implementing the framework in Java is two-fold: since Java is a quite popular development language, it may be easier for developers to familiarize with the framework and with the mechanisms to adapt it to their needs. Furthermore, we achieve portability, as the framework can be executed on any platform and operating system. 1http://docs.oracle.com/javaee/7/index.html 124 4.4 Implementation Guidelines As an example, Figure 4.9 shows the steps that a client application would perform in order to query trust-related information from the trust database. The client application would need to look up an instance of the trust server from the Java Naming and Directory Interface (JNDI) in order to invoke the query API call, implemented by EJBs (Enterprise Java Beans) that connect to an SQL server by means of a Java Database Connectivity (JDBC) connector. Figure 4.9: Query API Call Sequence Diagram loop More Data Client Application API Client JNDI Trust API Services SQL Server initialize lookup get trust API call resultSet := EJB API call JDBC Query In the next sections, we elaborate on some implementation ideas for different architectural elements and concepts. 4.4.1 Context As we mentioned in Section 2.2.3, the context is very important in the trust and reputation domains. Every trust relationship and reputation score make sense in a single context and cannot (usually) be transferred directly to another context. In order to take into account the context, whenever an event is triggered, the developer introduces a string that represents this context. It will then be stored together with all the rest of trust or reputation information, as explained in the next section. 4.4.2 Database Tables An RDBMS such as SQL can be the implementation choice in order to store persistently all the trust-related information. The tables design is of paramount importance for the efficiency and correct behaviour of the framework, as they may support more or less easily the implementation of the concepts discussed above. As an example, we propose 125 4. ENABLING TRUST AND REPUTATION DURING IMPLEMENTATION Table 4.1, Table 4.2, Table 4.3 and Table 4.4. For each one, we explain the main attributes they should hold and their meaning. Table 4.1: Entity Table Attribute Description ID Unique identifier Type Human, Non-Human or Reputation Statement Reputation Reputation score Context Context where this information applies Claim Type of the claim that corresponds to this evaluation Time Indicates when this reputation score was first created LastTime Indicates the last time this entity’s reputation was changed Number of evaluations Number of evaluations made on this entity Table 4.2: Trust Relationship Table Attribute Description ID Unique trust relationship identifier ID Trustor The unique identifier of the entity placing trust ID Trustee Unique identifier of the entity onto which trust is placed Trust value Trust value placed by the trustor on the trustee Context Context where this trust relationship holds Number of updates Times that the value of this relationship has changed Time Indicates when this trust relationship was first established Last Time Indicates when this trust relationship was last updated Primary keys could be a made up of the ID and the Context, since the same entity could hold different trust or reputation values for different contexts. Unique identities could be the foreign keys used in order to relate tables among each other. The Data Manager component must provide the interface required to set and obtain most of this information. For this purpose, it uses a JDBC connector in order to translate from Java method calls to SELECT, INSERT and UPDATE SQL statements. Given that this can be complex, a suitable, more maintainable design approach would 126 4.4 Implementation Guidelines Table 4.3: Reputation Statement Table Attribute Description ID Unique identifier Source Source entity’s ID Target Target entity’s ID Claim Name of the claim Claim value The value of the claim Context Context where the statement is applicable Time Time when the claim was made Table 4.4: Beliefs Table Attribute Description ID The unique identifier of the belief (e.g. capability, honesty, ...) Source Source entity’s unique ID Target Target entity’s unique ID Value Belief value Context Context where this belief is applicable be to create different objects to manage each table. The API translator would be split into a mediator object that delegates the queries to these specialized objects. Thus, one object would not need to know how to interact with all the database tables. Note that these tables support taking the trustor’s subjective factors into account. In order to compute the rating bias of an entity, the Data Manager would first retrieve all the claims made by the entity, normalize them (in order to consider different types of claims with different scales), and then compute the average and the standard deviation. This can be achieved by looking up the Reputation Statement table (see Table 4.3). Another implementation choice would be using an Object-Oriented Database Management System (OODBMS), which provides higher flexibility and avoids the tedious mapping between two representation models (i.e. from objects to relational tables), as they allow storing objects directly. This simplifies greatly the implementation of the Data Manager, which would basically become a direct mediator between an API call 127 4. ENABLING TRUST AND REPUTATION DURING IMPLEMENTATION and the database system, without requiring the translation process. However, RDBMS are often more efficient, above all when considering simple objects and relationships. 4.4.3 Messaging Infrastructure The main components of the architecture communicate with each other via asynchronous, optimistic queue-based messaging system, which could be implemented onto the Java Message Service (JMS). This solution scales well in the presence of many entities, which can continue their operations in most cases without the need to wait for results from the framework. Whenever a new event is triggered, the client application does not wait for a response from the server, but it continues doing other tasks. The application knows that the trust server will eventually update the trust relationships and reputation scores, but there is no hard time limit. The same happens in the case of the Event Handler,Engine Dispatcher and Data Manager components. They are listening to their specific queues. As soon as a new piece of information arrives, they take it out from the queue, process it, and place it in another queue for further processing. This way, the framework can adjust, on-demand, the number of instances of the same component that is listening to a queue, providing higher performance and scalability. This is especially true for the Data Manager, which can receive queries and writes requests from different components: the Trust Statement Queue, the Engine Dispatcher, the Event Handler, and even from the client application. Therefore, many instances could be concurrently listening to queries from these sources. 4.4.4 Engines When an Engine Dispatcher instance reads a reputation statement, it uses an Engine Factory to create the appropriate Engine to deal with such statement. The Engine Factory creates an engine by inspecting computation rules, which define which type of engine to create under which circumstances. This can be implemented as an XML file that the factory reads. This file includes a set of conditions and an effect, which states the engine type to build. A simple example is shown in Listing 4.1: Listing 4.1: Engine Configuration 1 <CompRule RuleId = ‘ ‘CompRule CounterUp ’ ’ Engine = ‘ ‘ CounterUp ’ ’> 2 <Context>Film Review</Context> 3 <Claim>P ositi v e Vote</Claim> 128 4.4 Implementation Guidelines 4 <Source> 5 <SourceType>Human</SourceType> 6 </ Source> 7 <Target> 8 <TargetType>Non−Human</TargetType> 9 </Target> 10 </CompRule> This file specifies that if the context of the reputation statement is Film Review, the claim is Positive Vote, the type of the source of the reputation statement is Human, and the type of the target of the reputation statement is Non-Human, then the engine to apply is CounterUp. The Engine Factory would read the file (through another XML reader object), compare the conditions against the reputation statement fields, and create an instance of this type of engine. Listing 4.2 shows how the class EngineManager would work. Listing 4.2: Excerpt of EngineManager 1public f i n a l cl as s EngineManager { 2 3// . . . more s t u f f 4 5//A Reputation Statement Reader instance s i g n a l l e d t hat a new reput at io n statement has arrived . 6public void onNewReputationStatement ( ReputationStatement rs ) { 7 Engine [ ] e = EngineFactory . getEngine ( rs ) ; 8//e [ 0 ] holds an instance of the reputation engine 9// e [ 1 ] holds an insta nc e of the t r u s t engine 10 i f ( e [ 0 ] != null ) { 11 reputation = e [ 0 ] . compute ( rs ) ; 12 } 13 i f ( e [ 1 ] != null ) { 14 t ru st = e [ 1 ] . compute ( ts ) ; 15 } 16 // tsw i s an inst an ce of a t r u s t statement writer , a JMS c l i e n t 17 // which a c t u a l l y knows how to send data to which queue 18 tsw . write (new TrustStatement ( rs , e [ 0 ] , e [ 1 ] ) ) ; 19 } 20 } 129 4. ENABLING TRUST AND REPUTATION DURING IMPLEMENTATION 4.4.5 Deployment The decision on how deployment is done is of paramount importance when pursuing high performance behaviour in environments with thousands of entities. There are several choices: •Everything on the same machine: this is the simplest deployment option. It does not scale and does not allow for failover capabilities in case of electrical problems. •The application server on one machine, the trust server and the RDBMS server on other machine: an intermediate solution where the trust server can be replicated on-demand, offering a higher scalability. •Everything on different machines: this is the most flexible choice, although it is more vulnerable to network and bandwidths problems. As an example, Figure 4.10 shows the first and the third deployment options discussed above. Figure 4.10: Two Deployment Configurations JavaEE Server Application Server Client Application Trust API Application Server SQL Server Client Application Trust API SQL Server JMS JMS RMI JDBC The next section ties together all the concepts discussed here by showing how the framework can be applied in a social cloud scenario. 4.5 Application Example: Social Cloud This section presents a motivating scenario that would benefit from the use of the presented framework. We describe the scenario, its trust and reputation requirements 130 4.5 Application Example: Social Cloud and how the framework can be used in order to implement these requirements. 4.5.1 Scenario Description The scenario that will be used as benchmark to validate our framework is the following. A developer needs to implement a social website for cloud providers. Cloud providers can register in the site. Once registered, they can publish web services on the site by posting a full description of the service, including the API calls (e.g. by using Web Service Description Language (WSDL)). Cloud providers can also look up a web service according to their needs, and use the service in order to create a larger, composed web service. When one cloud provider consumes a service from another provider, the latter can charge the former according to the type or complexity of the service. Thus, the site acts as a software market between cloud providers, following the software as a service model. Eventually, each cloud provider will use its own infrastructure to provide the resulting services to their customers, although this is out of the scope of the scenario. Figure 4.11 depicts the main elements of the scenario together with trust and reputation considerations that are further explained in the following section. 4.5.2 Trust Requirements The underlying framework must enforce trust and reputation requirements in order to prevent risks for the cloud providers and to foster trust in the site. There are two basic reputable entities in this scenario: cloud providers and web services. Each of them might have a reputation value that can be derived from the personal opinions and feedbacks from other providers in the site. For example, if a provider uses a service and notices that the service is not running appropriately, it could rate negatively the service, which in turn could negatively affect the service provider’s reputation. In addition to reputation, cloud providers can establish trust relationships among themselves. The way trust and reputation are computed depends on the models implemented, and the developer of the website should be provided with mechanisms to decide which model to use at design-time. For a particular instance of this scenario, we focus on a small subset of possible trust requirements: 131