In this paper, we present STS-Tool 3.0: a software tool that helps security requirement engineers in maintaining high level of security in socio-technical systems. STS-Tool 3.0 allows to specify social/organizational security requirements and to enforce them in part of the implementation of socio-technical systems.
Socio-technical systems are an interplay of social (human and organizations) and technical subsystems, which interact with one another to reach their objectives. Examples of socio-technical systems are smart cities, air traffic management systems and payment systems, i.e. systems where banks, payment services and e-shops interact to transfer monetary values.
Subsystems in socio-technical systems are autonomous, heterogeneous and weakly controllable, but they highly depend on each other. For example, in the payment system the banks and payment services are autonomous but without interacting with each other, both of the systems will not be able to transfer monetary values.
In such interconnected environment is central maintaining a high level of security: a security issue of one subsystem may cause a chain reaction and impact many other subsystems. For example, in a payment socio-technical system, a security issue on the information integrity of the payment orders in one of the banks might compromise the entire system: all the banks and payment services that use the compromised bank may have received payment orders containing unauthorized modifications.
Therefore, it is essential maintaining the level of security specified by the stakeholders, i.e. being sure that security requirements are enforced in socio-technical systems’ implementation.
In previous work [
In this paper we illustrate STS-Tool 3.0, the tool that supports the framework
proposed in [
The paper is structured as follows. Section 2 introduces the architecture and the implementation of STS-Tool 3.0, while Section 3 describes the content of the demonstration. Section 4 contains the related work and Section 5 concludes. 2
STS-Tool 3.0 has the ambitious objective of supporting the generation of the implementation of socio-technical systems that enforces of social/organizational security requirements.
Such security requirements are based on high-level of abstraction concepts, such as goals/objectives of actors and delegation of goals/objectives, but, due to the conceptual gap between these concepts and the implementation, it is not possible to directly generate the code that enforces the security requirements.
STS-Tool 3.0 uses business process models to bridge the conceptual gap. It
generates business processes, from social/organizational models, that are refined by security
requirement engineers and then it transforms such business processes in the
implementation. Specifically it uses using STS-ml [
The generation of a secure implementation of socio-technical systems needs business processes that enforce the social/organizational security requirements. STS-Tool 3.0 verifies the enforcement of security requirements by transforming them in security policies, i.e., security requirements in terms of business process elements, and it verifies such policies against the business processes.
STS-Tool 3.0 extends version 2.0, with a number of features, the most relevant are specified below: – generation of business processes from the social/organizational perspective; – generation of procedural security policies from social/organizational security requirements; – verification of business processes against procedural security policies; – generation of part of implementation of socio-technical system. Model editors
Model transformers Automated reasoners
STS-ml editor
SecBPMN2-ml editor
SecBPMN2-Q
editor SecBPMN2-ml generator
SecBPMN2-Q
generator
STS-ml consistency verifier
SecBPMN2 enforcement
verifier SecBPMN2-ml editor It permits to specify and to modify business processes with security aspects, using SecBPMN2-ml. This components extends BPMN2 Modeler1: an Eclipse2 plug in for drawing BPMN 2.0 diagrams SecBPMN2-Q editor It permits to model security policies using SecBPMN2-Q. This component, like SecBPMN2-ml editor, extends BPMN2 Modeler.
SecBPMN2-ml generator It automatically generates SecBPMN2-ml diagrams from STS-ml diagrams. SecBPMN2-ml diagrams are generated already filled with SecBPMN2-ml elements that can be derived from STS-ml diagram.
SecBPMN2-Q generator It generates SecBPMN2-Q security policies from security requirements specified in STS-ml diagram.
Transformation rules editor This component permits to visualize and modify transformation rules, i.e. set of rules used to generate the SecBPMN2-ml and SecBPMN2-Q models from, respectively, STS-ml models and the list of social/organizational security requirements.
SecBPMN2 enforcement verifier It is a verification engine that verifies if
SecBPMN2Q security policies are enforced in SecBPMN2-ml business processes. It generates a list
of SecBPMN2-ml elements that do not satisfy the security policy and a list of STS-ml
elements that are connected to the business process that does not satisfy the security
policy. These elements are highlighted in the editors to facilitate their identification.
River generator It generates part of socio-technical system implementations. The
component uses River [
SecBPMN2 enforcement verifier component
The SecBPMN2 enforcement verifier, described in this subsection, is the core part of
STS-Tool 3.0. We used DLV K [
Figure 2 shows the architecture of the component: grey boxes are software components, white boxes are input/output artifacts, while dashed arrows connect the inputs/outputs of the component to internal components.
STS project
SecBPMN2-Q diagram
STS-ml diagram
SecBPMN2-ml diagram
Mapping
STS-ml
SecBPMN2
SecBPMN2 enforcement verifier
SecBPMN2-Q
Parser
SecBPMN2-ml
Parser Mapping SecBPMN2
Goal
Plan
Knowledge
Base DLV software engine
Configuration parameters Output parser
Strategy
List SecBPMN2ml elements
Mapper
STS-ml List STS-ml elements
SecBPMN2 enforcement verifier receives in input STS project that is composed of: STS-ml diagram, SecBPMN2-ml diagram, SecBPMN2-Q diagram and Mapping STSml-SecBPMN2. The latter part of the input contains the links between STS-ml elements and SecBPMN2-ml elements. It is created during the generation of SecBPMN2-ml diagrams from STS-ml diagrams. SecBPMN2-ml parser receives in input a SecBPMN2ml diagram and it creates a Plan and the Knowledge base, i.e., the list of elements of the business process. Similarly SecBPMN2-Q parser component receives in input a SecBPMN2-Q diagrams and it creates a set of Goals. The DLV software engine has 1 6 Requirements
document strict limitations on the names of the variables and constants, therefore, the SecBPMN2ml parser and SecBPMN2-Q parser generate names that are compliant with the DLV limitations and store in a file called Map IDs SecBPMN2 the relations between the name of activities, in SecBPMN2-ml diagrams, and the generated names. The DLV software engine checks the Goal against the Plan using the Knowledge based and it generates, if possible, a plan, i.e. a list of actions. Output parser uses the MapIDs SecBPMN2 to generate, from the plan, a sequence of SecBPMN2-ml elements that, if executed, will satisfy the security policies. Finally, Mapper STS-ml uses the list and Mapping STS-mlSecBPMN2 to generate the list of STS-ml elements. 3
We illustrate STS-Tool 3.0 with the payment engine example (Example 1) following the phases of the process shown in Fig. 3.
River projects
SecBPMN2-Q security policy
Example 1 (Payment Engine). SAP Payment Engine (PE) [
Tranform S/O
model in procedural model
Model procedural security aspects STS-ml Diagram
SecBPMN2-ml
Diagram Enforce procedural security aspects
Verify security 5 policies against procedural aspects
Transform security requirements in security policies 3 4
STS-ml security requirements programmers only have to create one interface to transmit the required data to the PE system. The payment system is a socio-technical system since it involves customers, banks, the PE, etc., which interact with each other to perform payments. Phase 1 It supports the modeling of socio/organizational aspects of the socio-technical system under consideration. Figure 4 shows a screen shot of STS-Tool 3.0 with an STS-ml diagram in the upper part. Such modelling language focuses on representing the main stakeholders (e.g. PE and Bank in Fig. 4), their objectives, as well as their interactions (e.g. Fig. 4 the objective Transfer performed is delegated from the PE to Bank). Most importantly, it captures security requirements. For example, in Fig. 4 Auth (authorization) and Ava (availability) security requirements are specified. Phase 2 It deals with the transformation of social/organizational models to business processes, receiving in input a social/organizational diagram and generating a procedural diagram of the system-to-be. STS-Tool 3.0 uses SecBPMN2-ml as modelling language for business process with security aspects. It permits to model participants (e.g., PE and Bank in SecBPMN2-ml diagram shown in Fig. 4) that execute activities (e.g., Perform transfer in Fig. 4) and exchange messages (e.g. Transfer order in Fig. 4). Such modeling language permits to specify security concepts using security annotations, such as the orange solid circle in Fig. 4 that represents confidentiality of the message transmitted in the communication between the two participants.
Phase 3 Social/organizational models do not contain the information required to generate complete SecBPMN2-ml models. Therefore, this phase is executed to enrich the SecBPMN2-ml models generated by phase 2 with details such as the temporal aspects and security choices on the executed processes.
Phases 1-3 are repeated until security requirement engineers decide they have captured all important (security) details and the procedural model is complete and accurate. Phase 4 It generates procedural security policies from social/organizational security requirements. This phase permits to translate security requirements, defined in terms of social/organizational concepts, in more operational constraints, as the ones specified in security policies. STS-Tool 3.0 uses SecBPMN2-Q as modeling language for security policies. Figure 4 shows an example of SecBPMN2-Q diagram. Such modelling language extends SecBPMN2-ml, since it permits to use relations such as path, represented with a dashed arrow in Fig. 4.
Phase 5 It deals with the verification of procedural security policies, generated in phase 4, against the procedural model, enriched in phase 3. This phase validates SecBPMN2ml models by verifying if they enforce the security requirements specified in the social/organizational model. If all security policies are enforced, then the security requirement engineers have the proof that the procedural model meets the security requirements. If the procedural model does not satisfy all procedural security policies, the process starts from the beginning.
Phase 6 It consists in generating part of the implementation from the enriched and
verified procedural model. The resulting application will enforce the social/organizational
security requirements, because social/organizational security requirements define the
security policies that are verified against the procedural model. Therefore, because the
transformation enforces all the security aspects defined in the procedural model, the
implementation can be considered secure. For further details, see [
As far as our knowledge goes, no software tool assists security requirement engineers in enforcing security requirements from their early specification until the implementation in socio-technical systems. 5
STS-Tool 3.0 is ready for public use. This version of the tool is the result of an
iterative development process, having been tested on multiple case studies and evaluated
with practitioners [
This research was partially supported by the ERC advanced grant 267856, ‘Lucretius: Foundations for Software Evolution’, www.lucretius.eu.