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 language (using i *-like primitives such as actor, goal, delegation) for the design of secure STSs. STS-ml represents security requirements as constraints 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 sophisticated reasoning mechanisms to detect con icts in security requirements.
Socio-Technical Systems (STSs) are an interplay of social (human and
organisations) and technical subsystems, which interact with one another to reach
their objectives, making an STS a network of social relationships [
To deal with security in the early phases of STS design, we have previously
proposed STS-ml [
STS-ml speci es 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 speci cations guide the design of a STS that satis es the security requirements. However, in certain cases, the speci cation may be inconsistent, i.e., one or more requirements might be con icting. It is, thus, not possible to implement a STS that satis es all requirements of the speci cation.
Coping with such con icts at requirements-time avoids developing a
noncompliant and hard-to-change system. We propose to rely on automated
reasoning to identify and resolve these con icts. This choice is justi ed by our gathered
evidence [
We aim at creating a framework that supports the identi cation of inconsistencies (con icts) among security requirements in a STS-ml speci cation. We focus on two types of con icts: (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 di erent authorisations are con icting, 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 con icts by looking at the graphical models, others are harder to spot|especially in large models|and require computeraided support. To such extent, we have formalised the semantics of the STS-ml primitives and that of its security requirements. This e ort enables us developing automated reasoning techniques for the identi cation of con icts. Our longerterm objective is to support the resolution of con icts too. 3
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 con icts 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 supports the graphical visualisation of con icts in STS-ml diagrams. 3.1
The STS-ml framework for security requirements engineering
STS-ml has been rst proposed in [
delegation, etc. Security requirements in STS-ml models are mapped to social
commitments [
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 ight service as an agent, as it refers to a speci c ight 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 information it makes tangible is also altered. For instance, the Amadeus ight service modi es 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 (prohibited) to do, for which goals (scope), and whether authorisation can be further transferred or not. For instance, Tourist authorises TAS to use (U selected) information 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 di erent requirements types: { Business policies are expressed by specifying actors, their goals, delegations, document provisions, and how actors manipulate documents to ful l goals.
In a nutshell, they are represented by an actor's goal model.
document provision agent
role goal delegation
Tabs to change views interaction reqsueicruemriteynts
List of security requirements (a) Social view Textual description of requirements organisational constraint goal
document authorisation requirements (b) Information view
(c) Authorisation view { Interaction (security) requirements are security constraints on goal delegations and document provisions. STS-ml supports non-repudiation, four types of redundancy, no-redelegation, availability and integrity-of-transmission interaction security requirements. For instance, TAS requires the Amadeus ight service not to repudiate the delegation of goal Flight tickets booked, and also not to redelegate this goal. The Amadeus ight 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 de ne also prohibitions over the same information. In this category, STS-ml supports nonreauthorisation, need-to-know of information, non-usage, non-modi cation, 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-modi cation, 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, demanding it to be used only for the speci ed 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 organisational 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 con icts in security requirements
We are concerned with the veri cation of two types of inconsistencies that relate
to security requirements: (i) identifying con icts among security requirements,
that is, verifying whether the simultaneous speci cation of di erent security
requirements brings up con icts; and (ii) identifying con icts raised by the speci
cation of the security requirements with respect to an actor's business policy. For
each of these two categories, we identify con icts in our running example, and
provide insights on how they could be xed. Here we provide just the intuition
behind the identi cation of these con icts. The formal framework, its
implementation in disjunctive Datalog, and experimental results from an industrial case
study on eGovernment are presented in a technical report (see [
The rst challenge is to obtain a set of security requirements that is consistent, which enables us to build a secure socio-technical system (that violates no security requirement). The focus of STS-ml is mainly on information security; thus, we have begun by tackling authorisation con icts. Detecting con icts among other types of security requirements is still work in progress.
For instance, the Tourist does not authorise the Amadeus ight service to use his/her Personal Data, while TAS authorises the Amadeus ight service to use Tourist 's Personal Data. This situation represents an authorisation con ict for the Amadeus ight service. Speci cally, this con ict relates to the \use" operation. Our framework supports also con icts about modi cation, production, distribution, and authorisation transferibility (i.e., an actor is granted authorisation to perform operations but not that of further distributing the authorisation).
The second challenge is to verify if one or more security requirements con ict 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 speci es a no-redelegation security requirement over the delegation of the goal Hotel booked, there is a con ict 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 con ict. The Amadeus ight service modi es Flight tickets when achieving goal Flight tickets booked. Flight tickets makes tangible tourist's personal data, for which no authorisation on modi cation (M) is granted, instead a nonmodi cation authorisation requirement is speci ed. The Amadeus ight 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 ight tickets modi ed, or he/she should grant the permission to the Amadeus ight service. 4
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 various evaluations conducted with industrial partners of the FP7 European project Aniketos. The framework has proven suitable to model real case studies spanning from eGovernment to Air Tra c Management Control. STS-ml supports a rich set of security requirements, for which we can identify con icts.
Ongoing work includes di erent 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 de nition of access control policies.
Future work includes: (i) devising other reasoning techniques for more sophisticated reasoning, (ii) exploring techniques for con ict resolution, and (iii) reducing the learning curve for STS-ml, also via self-learning mechanisms. Acknowledgments. The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grants no 257930 (Aniketos) and 256980 (NESSoS).