Proceedings of the 6th International i* Workshop (iStar 2013), CEUR Vol-978 Designing Secure Socio-Technical Systems with STS-ml Elda Paja1 , Fabiano Dalpiaz2 , and Paolo Giorgini1 1 University of Trento, Italy – {elda.paja, paolo.giorgini}@unitn.it 2 University of Toronto, Canada – dalpiaz@cs.toronto.edu Abstract. A Socio-Technical System (STS) is an interplay of humans, organizations and technical systems. STSs consist of interacting actors, which depend on one another to achieve their objectives. In previous work, we have proposed STS-ml, a security requirements modelling lan- guage (using i*-like primitives such as actor, goal, delegation) for the design of secure STSs. STS-ml represents security requirements as con- straints over the interactions (goal delegation and document exchange) among actors in the STS. In this work, we present the current version of STS-ml, which introduces further modelling primitives as well as sophis- ticated reasoning mechanisms to detect conflicts in security requirements. 1 Introduction Socio-Technical Systems (STSs) are an interplay of social (human and organ- isations) and technical subsystems, which interact with one another to reach their objectives, making an STS a network of social relationships [1]. Each sub- system is a participant of the STS, acts according to its business policy (it is autonomous), and interacts with others. When relying upon others for carrying out tasks and manipulating information, a participant would like its own security requirements to be fulfilled. For example, if a buyer sends its personal data to a seller, the buyer may require the data to be used only for shipment purposes. To deal with security in the early phases of STS design, we have previously proposed STS-ml [2] (Socio-Technical Security modelling language), an actor- and goal-oriented security requirements modelling language. STS-ml is based on the idea of relating security requirements to interaction. As such, the language allows stakeholders to express security needs over their interactions to constrain the way interaction is to take place, as in the buyer/seller example above. STS-ml specifies security requirements as social commitments, promises with contractual validity made by an actor to another. One actor commits to another that, while delivering some service, it will comply with the required security needs. In the example above, a security requirement is that the seller commits not to disclose personal data to other parties. These specifications guide the design of a STS that satisfies the security requirements. However, in certain cases, the specification may be inconsistent, i.e., one or more requirements might be conflicting. It is, thus, not possible to implement a STS that satisfies all requirements of the specification. 79 Proceedings of the 6th International i* Workshop (iStar 2013), CEUR Vol-978 Coping with such conflicts at requirements-time avoids developing a non- compliant and hard-to-change system. We propose to rely on automated reason- ing to identify and resolve these conflicts. This choice is justified by our gathered evidence [5] that requirements models are large and that even skilled analysts would be unable to identify all the conflicts in a model. 2 Objectives of the research We aim at creating a framework that supports the identification of inconsisten- cies (conflicts) among security requirements in a STS-ml specification. We focus on two types of conflicts: (1) among security requirements: two or more security requirements cannot be implemented by the same system. For instance, access to some information may be granted from one stakeholder, and prohibited from another. The different authorisations are conflicting, and one of them needs to be relaxed and adapted, perhaps by negotiating the needs of the authorisee; and (2) between actors’ business policies and security requirements: an actor’s policy may specify that some information shall be accessed, while no authorisation is granted by the information owner. We provide examples in Sec. 3.1. While analysts may detect some conflicts by looking at the graphical models, others are harder to spot—especially in large models—and require computer- aided support. To such extent, we have formalised the semantics of the STS-ml primitives and that of its security requirements. This effort enables us developing automated reasoning techniques for the identification of conflicts. Our longer- term objective is to support the resolution of conflicts too. 3 Scientific contributions STS-ml is an actor- and goal-oriented security requirements engineering method. It is composed of the modelling language and its support tool STS-Tool 3 . The contributions of this research are as follows: – a revised version of the STS-ml language, including a wider set of security requirements; – a formal framework to identify conflicts among security requirements, as well as among actors’ business policies and the security requirements they are required to comply with; – an implementation of the framework in disjuctive Datalog. STS-Tool sup- ports the graphical visualisation of conflicts in STS-ml diagrams. 3.1 The STS-ml framework for security requirements engineering STS-ml has been first proposed in [2], here we present the current version of STS-ml. STS-ml includes high-level organisational concepts such as actor, goal, 3 http://www.sts-tool.eu 80 Proceedings of the 6th International i* Workshop (iStar 2013), CEUR Vol-978 delegation, etc. Security requirements in STS-ml models are mapped to social commitments [4]—contracts among actors—that actors in the STS shall comply with at runtime. STS-ml modelling consists of three complementary views of the same model, namely social, information, and authorisation view (see Fig. 1), so that different interactions among actors can be analysed by concentrating on a specific view at a time. Interview consistency is ensured by STS-Tool 4 . Example 1 (Travel Planning). A tourist wants to organise a trip using a Travel Agency Service (TAS ). TAS allows end users to read about various destinations, book flights and hotels, hire a car, etc., and uses the Amadeus flight service to book flight tickets. To book hotels, the Tourist has chosen to directly contact the Hotel himself, without interacting with TAS. The social view (Fig. 1a) represents actors as intentional and social entities. Actors are intentional as they aim to attain their goals, and they are social, for they interact with others by delegating goals and exchanging documents. STS-ml supports two types of actors: agents—concrete participants, and roles— abstract actors, used when the actual participant is unknown. In our example, we represent the TAS as a role, and the Amadeus flight service as an agent, as it refers to a specific flight service. Actors may possess documents, they may use, modify, or produce documents while achieving their goals. For instance, Tourist wants to achieve the goal trip planned, for which it needs to both have tickets booked and hotel booked. To book the hotel it needs document ID Doc copy. The information view (Fig. 1b) gives a structured representation of actors’ information and documents, and the way they are interconnected. Information can be represented by one or more documents (through TangibleBy), and on the other hand one or more information entities can be part of some document. For instance, information Personal data is represented by both ID Doc copy and Flight tickets documents. We keep track of how information and documents are interconnected to identify which information actors manipulate, when they use, modify, produce, or distribute documents to achieve their goals. We take a pessimistic approach assuming that whenever a document is altered, the infor- mation it makes tangible is also altered. For instance, the Amadeus flight service modifies information Personal data when modifying document Flight tickets. The authorisation view (Fig. 1c) shows the authorisations actors grant to others over information, specifying which operations they are allowed (prohib- ited) to do, for which goals (scope), and whether authorisation can be further transferred or not. For instance, Tourist authorises TAS to use (U selected) in- formation Personal data and Itinerary in the scope of the goal Tickets booked granting a transferrable authorisation (authorisation’s arrow line is continuous). Through its three views, STS-ml supports different requirements types: – Business policies are expressed by specifying actors, their goals, delegations, document provisions, and how actors manipulate documents to fulfil goals. In a nutshell, they are represented by an actor’s goal model. 4 http://www.sts-tool.eu 81 Proceedings of the 6th International i* Workshop (iStar 2013), CEUR Vol-978 Tabs to change views agent role document provision organisational constraint goal interaction security requirements document goal delegation List of security requirements Textual description of requirements (a) Social view authorisation requirements (b) Information view (c) Authorisation view Fig. 1: Multi-view modelling for the travel planning scenario – Interaction (security) requirements are security constraints on goal delega- tions and document provisions. STS-ml supports non-repudiation, four types of redundancy, no-redelegation, availability and integrity-of-transmission in- teraction security requirements. For instance, TAS requires the Amadeus flight service not to repudiate the delegation of goal Flight tickets booked, and also not to redelegate this goal. The Amadeus flight service, on the other hand, requires that the integrity of document Itinerary details is preserved. – Authorisation requirements determine which information can be used, how, for which purpose, and by whom; at the same time they define also prohi- bitions over the same information. In this category, STS-ml supports non- reauthorisation, need-to-know of information, non-usage, non-modification, 82 Proceedings of the 6th International i* Workshop (iStar 2013), CEUR Vol-978 non-production and non-disclosure of information. While authorising TAS to use (U selected) information Personal data and Itinerary in the scope of the goal Tickets booked, the tourist is prohibiting TAS to perform the rest of operations, requiring non-modification, non-production and non-disclosure of the given information. Moreover, since authorisation is limited to a goal scope, this expresses a need-to-know requirement over information, demand- ing it to be used only for the specified scope; – Organisational constraints determine constraints on the adoption of roles and the uptake of responsibilities. STS-ml supports separation and binding of duties both over roles and over goals. For instance, a separation of duty is expressed between goals Flight tickets booked and Train tickets booked requiring TAS not to ever achieve both these goals. Together, interaction requirements, authorisation requirements, and organi- sational constraints are the security requirements of STS-ml. A STS-ml model is consistent if the actors’ business policies comply with the security requirements. 3.2 Detecting conflicts in security requirements We are concerned with the verification of two types of inconsistencies that relate to security requirements: (i) identifying conflicts among security requirements, that is, verifying whether the simultaneous specification of different security re- quirements brings up conflicts; and (ii) identifying conflicts raised by the specifi- cation of the security requirements with respect to an actor’s business policy. For each of these two categories, we identify conflicts in our running example, and provide insights on how they could be fixed. Here we provide just the intuition behind the identification of these conflicts. The formal framework, its implemen- tation in disjunctive Datalog, and experimental results from an industrial case study on eGovernment are presented in a technical report (see [3]). The first challenge is to obtain a set of security requirements that is con- sistent, which enables us to build a secure socio-technical system (that violates no security requirement). The focus of STS-ml is mainly on information secu- rity; thus, we have begun by tackling authorisation conflicts. Detecting conflicts among other types of security requirements is still work in progress. For instance, the Tourist does not authorise the Amadeus flight service to use his/her Personal Data, while TAS authorises the Amadeus flight service to use Tourist’s Personal Data. This situation represents an authorisation conflict for the Amadeus flight service. Specifically, this conflict relates to the “use” op- eration. Our framework supports also conflicts about modification, production, distribution, and authorisation transferibility (i.e., an actor is granted authorisa- tion to perform operations but not that of further distributing the authorisation). The second challenge is to verify if one or more security requirements conflict with the private business policy of an actor (as dictated by its goal model). For instance, suppose the Hotel ’s business policy requires handling all bookings by means of a reservation system service. When Tourist specifies a no-redelegation security requirement over the delegation of the goal Hotel booked, there is a 83 Proceedings of the 6th International i* Workshop (iStar 2013), CEUR Vol-978 conflict between what the security requirement demands the Hotel to do, and what its internal requirement dictates. Let us show another example of this kind of conflict. The Amadeus flight service modifies Flight tickets when achiev- ing goal Flight tickets booked. Flight tickets makes tangible tourist’s personal data, for which no authorisation on modification (M) is granted, instead a non- modification authorisation requirement is specified. The Amadeus flight service might need to modify Flight tickets to accommodate changes in the itinerary of the Tourist, so either the Tourist decides he/she does not want the flight tickets modified, or he/she should grant the permission to the Amadeus flight service. 4 Conclusions, ongoing and future work STS-ml is a framework to model and reason over security requirements for STSs. The current version of the framework is a result of an iterative approach, of vari- ous evaluations conducted with industrial partners of the FP7 European project Aniketos. The framework has proven suitable to model real case studies span- ning from eGovernment to Air Traffic Management Control. STS-ml supports a rich set of security requirements, for which we can identify conflicts. Ongoing work includes different directions: (i) developing a new version of the tool with improved usability, and (ii) exploring how STS-ml can inform later phases in the design of secure STSs, e.g., the definition of access control policies. Future work includes: (i) devising other reasoning techniques for more so- phisticated reasoning, (ii) exploring techniques for conflict resolution, and (iii) reducing the learning curve for STS-ml, also via self-learning mechanisms. Acknowledgments. The research leading to these results has received fund- ing from the European Union Seventh Framework Programme (FP7/2007-2013) under grants no 257930 (Aniketos) and 256980 (NESSoS). References 1. F. Dalpiaz, P. Giorgini, and J. Mylopoulos. Adaptive Socio-Technical Systems: a Requirements-driven Approach. Requirements Engineering, 18(1):1–24, 2013. 2. F. Dalpiaz, E. Paja, and P. Giorgini. Security Requirements Engineering via Com- mitments. In Proceedings of the First Workshop on Socio-Technical Aspects in Security and Trust (STAST), pages 1–8, 2011. 3. E. Paja, F. Dalpiaz, and P. Giorgini. Identifying Conflicts in Security Require- ments with STS-ml. TR DISI-12-041, University of Trento, http://disi.unitn. it/~paja/tr-identifying-sec-conflicts.pdf, 2012. 4. M. P. Singh. An Ontology for Commitments in Multiagent Systems: Toward a Unification of Normative Concepts. Artificial Intelligence and Law, 7(1):97–113, 1999. 5. S. Trösterer, E. Beck, F. Dalpiaz, E. Paja, P. Giorgini, and M. Tscheligi. Forma- tive User-Centered Evaluation of Security Modeling: Results from a Case Study. International Journal of Secure Software Engineering, 3(1):1–19, 2012. 84