Socio-Technical Systems (STSs) are complex systems composed of both social (i.e., humans and organizations) and technical (i.e., hardware and software) elements. Security requirements for STSs define constraints for the sociotechnical interactions and can be specified as a set of security policies that have to be satisfied by the components of the system during their interactions. In this paper, we present how security requirements molded in STS-ml are transformed in security policies expressed in SecBPMN, an extension of BPMN with security annotations.
Socio-Technical Systems (STSs) are complex systems where both social and technical
components interact one another to achieve shared goals. Smart cities, health care, Air
Traffic Management (ATM) systems are only few examples of STSs. In STSs,
security requirements identify constraints interactions that have to be satisfied by the
components of the system during their activities. STS-ml [
STS can be modeled in terms of business processes, where activities are assigned
and executed by single components and the control flows regulate their interactions.
SecBPMN [
STS-ml and SecBPMN models express different aspects of STSs, in particular SecBPMN models specify STS-ml models, hence both models are needed to fully characterize STSs. Specifying STS-ml security requirements in terms of SecBPMN security policies is a complex and time consuming activity that calls for automated support. This is particularly true in STSs where the high number of security requirements and their complexity make very hard and error prone this activity. In this paper, we propose a set of transformation rules to partially automate the specification STS-ml security requirements in SecBPMN security policies.
The paper is structured as follows. Section 2 describes STS-ml and SecBPMN while Section 3 contains the transformation rules. Section 4 concludes the paper and proposes possible future work. 2
This Section briefly describes STS-ml and SecBPMN, i.e. the two languages we used to model socio-technical security requirements and security policies. 2.1
STS-ml
Many security requirements modeling languages have been proposed so far. For
example, SI* [
In STS-ml, requirements models are expressed by three views: (i) the social view describes the main actors, their rationale, goal delegations, and document provisions; (ii) the information view defines the relationship between information and documents; and (iii) the authorization view represents the authorizations about information that actors grant one to another. Figure 1 shows an example of STS-ml model of an airport scenario. Social view. Two types of actors are modeled: agents—concrete entities that are known at design-time (e.g., Immigration office )—and roles—that can be played by different agents at runtime (e.g., Web-Service). An actor’s rationale is an AND/OR goal tree (e.g., the root goal of the Immigration Office is to be Immigration monitored). To achieve their goals, actors need, modify, and produce documents (e.g., Immigration Office needs document Visa to achieve goal Visa checked). Two social relationships link couples of actors: goal delegation and document provision. Both relations can be subject to security requirements (e.g., integrity, availability, . . . ).
Information view. Documents and information are linked one to another. The “Tangible by” relation indicates that an information is represented by a document. In Figure 1, Citizen SSN (Social Security Number) is made tangible by document Visa. Ownership relates an actor to the information that she owns.
Authorization view. It represents the permissions on information that actors grant one to another. An authorization box details the granted permissions (Use, Modify, Produce, Distribute) on documents representing specific information. Authorizations can be limited by defining a scope: one or more goals for whose fulfillment the permissions are granted. In Figure 1, the Web-Service authorizes the Immigration Office to use Citizen SSN in the scope of goal Visa checked. 2.2
SecBPMN [
SecBPMN-ml extends BPMN with security concepts about information assurance
and security defined in [
Figure 2 shows part of a SecBPMN-ml model of a business process used in an airport information system where users can use different web-interfaces to select the best option for a flight, buy tickets and perform most of the bureaucratic processes required to take the flight.
SecBPMN-Q is a graphical query language which permits to define security policies in terms of SecBPMN-ml elements. Figure 3 shows an example of the textual policy “The visa document must be sent through a secure channel, which assures the information will not be modified by third parties”, modeled with SecBPMN-Q. The graphical security policy is composed by two activities labeled “@X” and “@Y”, “@” symbol is used match any activities. The two activities are linked with a path relation (the arrow with two slashes in the middle) which matches all the paths between the source and target activity. The security policy is enriched with a message flow (represented as a dashed arrow) which transports data object called “Visa”. When executed, this security policy will match any message flow between any two activities which exchange the “Visa” data object. The “Visa” data object is linked to an integrity annotation, which means that has to be protected by unauthorized modifications. 3
This section describes a set of transformation rules, that are used to specify all types of STS-ml security requirements in SecBPMN security policies. STS-ml and SecBPMN modeling languages have different scopes and, hence, they model different set of concepts. Therefore, for each transformation rule we define one or more mapping relations which link STS-ml concepts with SecBPMN concepts.
In the rest of the section, for each STS-ml security requirement, we describe its semantic (the first sentence) and the transformation rule we defined. Table 1 shows the transformation rules and the mapping needed for the transformations. The first four transformations create anti-patterns, i.e. the security policy shall not be satisfied in any business processes, the other transformations create patterns, i.e. the security policy shall be satisfied by all business process. Such transformation rules can be used to partially automate the transition from STS-ml to SecBPMN models, in order to help security designers in the specification of SecBPMN models and security policies from STS-ml models. For example the security policy in Figure 3 is derived from the transformation rule of integrity security requirement, with the mapping g ) Visa. Non-disclosure(Goal g, Document d) The document d shall not be disclosed in order to achieve g , to unauthorized actors. The transformation consists in defining a security policy that matches all the message flows, from ACT and transmit the document d . Non-usage(Goal g, Document d) The document d shall not be used (i.e. read) to achieve goal g . We created a transformation rule which creates a security policy which the data object mapped to d ,i.e. DO , is read by the activity mapped to g , i.e. ACT .
order to achieve g . We transformed it in a security policy which contains an activity which reads and writes the same data object, i.e. it modifies the data object. Non-production(Goal g, Document d) The document d shall not be created in order to achieve g . It’s transformed in a policy which contains an activity which writes the data object DO .
Non-repudiation(Delegation(Goal g)) The acceptance of the delegation of goal g shall not be repudiated. It is transformed in a policy which contains an activity ACT , that is mapped to goal g , linked to a non-repudiation security annotation.
Redundancy(Goal g, Type t) Goal g shall be achieved with a redundancy strategy t . STS-ml defines two types of redundancy strategies: fall-back redundancy and true redundancy. We specified it in two security policies. For fall-back redundancy we define a policy which is satisfied by a path where there is at least an exclusive gateway between the main and the backup activities, which represents the decision to use the backup activity. For the true redundancy we define a policy which is satisfied when the two activities are executed in parallel paths. These policies require a mapping of g to two activities: a main activity the backup one.
Integrity(Document d) The document d shall not be modified by unauthorized users. We transformed it in a security policy which requires the integrity security annotation attached to the data objects that corresponds to the document d .
Availability(Goal g, Float a) The percentage of time g is achieved over of the total times that is requested, shall be higher than a . We transformed it in a policy which contains an activity linked to an availability security annotation. The level of availability a , is specified in the predicate which details the security annotation.
Trustworthiness(Goal g, Int t) Goal g shall be achieved by an actor with a level of trustworthiness greater than t . This is transformed in a policy which contains an activity linked to an authenticity security annotation. The trustworthiness level t is specified by the predicate which details the security annotation.
Non-delegation(Goal g, Actor a) Goal g shall not be delegated, by a , to other actors. This security requirement cannot be transformed in a security policy, because in SecBPMN there is no concept that can be mapped to actor.
Need to know(Document d, Goal g) All operations on document d shall be executed only for the purpose of achieving g . As the previous security requirement, this cannot be specified as a security policy, but it is implicitly verified when the the security policies of non-usage, non-modification and non-production are verified.
shall (not) play also r2 . These security requirements cannot be specified in security policies, because in SecBPMN there is no concept that can be mapped to actor. 4
In this paper, we have proposed a set of rules to transform security requirements, expressed with STS-ml, into security policies, expressed with SecBPMN. These transformation rules are intended to automatize the specification activity and then support the analyst in the security requirements engineering process for STSs.
Non-disclosure (Goal g, Document d) g) hACTi d) hDOi Non-usage (Goal g, Document d) g) hACTi d) hDOi Non-modification (Goal g, Document d) g) hACTi d) hDOi Non-production (Goal g, Document d) g) hACTi d) hDOi Non-repudiation (Delegation(Goal g)) g) hACTi
Redundancy (Goal g, Fall-back red.) g) hACT1i g) hACT2i Redundancy(Goal g, True red.) g) hACT1i g) hACT2i Integrity (Document d)
d) hDOi Availability (Goal g, Float a)
g) hACTi Trustworthiness (Goal g, Int t)
g) hACTi
As part of our future work, we will develop a software tool to automatically transform security requirements into security policies and we will define a language to support security analysts in defining their own transformation rules.
The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant no 257930 (Aniketos).