Socio-Technical Systems (STS) consist of people, software, hardware and organizational units. The pervasiveness and complexity of STSs make security analysis both particularly challenging and especially critical. Traditional security analysis techniques that address security in a piecemeal fashion (e.g. only for software, or only for business processes) are insu cient for addressing global security concerns and have been found often to leave serious STS vulnerabilities untreated. In this proposal, we aim at developing a comprehensive framework that consists of concepts, techniques and tools for designing secure STSs. In our framework, a STS consists of organizational goals and security requirements, businesses and industrial processes through which requirements are satis ed, software applications that support those processes, and system infrastructure that supports both processes and applications. We intend to propose a systematic process to analyze and design each part of the STSs, and nally provide an all-round security design for STSs.
Copyright c by the paper's authors. Copying permitted only for private and academic purposes.
Unfortunately, most existing approaches address security requirements in a piecemeal fashion, merely considering security issues for a particular narrow part, i.e. software, physical infrastructure, or business process. We argue that the security designs of di erent parts in STSs may in uence each other in certain ways. Currently, there are no formal approaches to connect all the design concepts in di erent system components and analyze their mutual impacts. Thus, no systematic, global means are proposed to design fully secure STSs.
To address this problem, we plan to develop a framework which consists of concepts, processes, and tools for designing secure socio-technical system by connecting di erent components with each other. This framework contributes in following aspects: 1) explicitly capture and represent causal relationships among di erent parts of a system to support the design in each part; 2) propose a systematic process to produce secure designs for each component | the synthesis of these designs is treated as the system design, which ful lls both organizational objectives and security requirements; 3) provide a systematic means to handle system changes, while continuously satisfy both organizational objectives and security requirements.
In the remaining part of this paper, we summarize the state of the art in Sec. 2, based on which we describe concrete research topics in Sect. 3. Sect. 4 shows our research approach that deals with the identi ed problems. Finally, the contribution of our work is summarized in Sect. 6. 2
In this section, we will summarize related work on the topic of system security analysis and design. We are able to categorize many of these works according to the analytical perspectives they hold. Speci cally, we consider following four perspectives: organizational settings, business processes, software applications and physical infrastructure. Work which falls outside of these classi cations are discussed in a separate subsection.
There are a number of research proposals which focus on ensuring security of organizational settings through
modeling interactions among social actors, as well as some social relationships (e.g. trust, delegation,
authorization) [
Security analysis which focuses on business processes aims to represent the security requirements in business
process models. Analysts can use these requirements to further design secure business processes [
Most security e orts have focused on the technical aspects of software. There are many security analysis
techniques which can represent either security attacks or security requirements, such as Abuse Case [
Currently, there are few security approaches that focus on the infrastructure domain. Jurjens considers secure
deployments in UMLsec [
Mouratidis and Jurjens connect security designs between the organization perspective and the software
perspective by combining Secure Tropos and UMLsec [
Finally, there is another research branch that address human factors in STSs. Tarimo et al. [
Compared to technically-focused software systems, the socio-technical systems extend their system boundaries to include several related components, namely organization, business process and infrastructure. Although the proposed components may overlap with each other to some extent, we use them to ensure security designs cover all important aspects of STSs. Our work aims at analyzing all these essential components and investigating connections between them.
Organization component includes high-level system requirements. The concerns about organizational settings (e.g. the organizational hierarchies and policies) are considered in this domain.
Business process component is considered the core part of STSs, as all organizational requirements are met through business processes, and as business processes provide instructions for both humans and software on how to work together to achieve speci c goals.
Software component provides concrete implementations for supporting the business process. In the meanwhile, it relies on the deployment of infrastructure.
Physical infrastructure component is the backbone of software applications. The performance of software applications highly depends on related infrastructures. In addition, they may also play a role in some activities in the business process.
Human factors are the major issues in STSs. Instead of addressing human in uences in an independent dimension, we consider them together with each of the above components. We aim to consider human reactions together with related system designs, which facilitate understanding human intentions.
Based on the above components, our work will take the organizational goals and security requirements, which are in the organization component, as the inputs. While the outputs are a set of designs in the three left components, which work together to ensure security of the systems. In this sense, we de ne the designs in the software component as Software Requirement Speci cations(SRS); the designs in business process component are Business Requirement Speci cations(BRS) and the designs in infrastructure component are Infrastructure Requirement Speci cations(IRS). Then the synthesis of all these designs is treated as the system speci cation, which satis es both organizational goals and security requirements. Thus, the design of STS is de ned as:
System Design = BRS+SRS+IRS Current studies only take into account one of these parts and leave assumptions on other parts, which may not be held in the target system. We argue that these three parts of system designs are highly involved with each other. Without a global view on all the parts, the system under development will be vulnerable.
As a result, my research problem is summarized as developing a framework of concepts, processes, and tools for globally designing secure socio-technical systems by synthesizing designs in three di erent components, namely business process, software and physical infrastructure. Speci cally, there are four research questions need to be addressed: 1) what are the interrelationships among the above components; 2) how to formally orchestrate analysis in di erent components to provide global security designs; 3) how to derive secure designs in each component; 4) how to adapt designs to handle system changes. 4
In this section, we propose a research approach, which addresses the security problems in each system component, in order to derive global secure designs for STSs. 4.1
To specify system designs, we apply the following three concepts Requirements (R), Speci cation (S) and Domain
assumption (D), proposed by Zave and Jackson [
Concretely, as shown in Fig.1, the organizational requirements are imported to the business process domain;
the design of the business process domains specify the requirements for the software domain, as well as the
infrastructure domain; the software domain should support business process, in the meanwhile shed light on the
requirements for the infrastructure domain; nally, the infrastructure domain should support the design in other
two domains. We use Tropos [
The traceability links are built from speci cations in one layer to requirements in other layers, not to speci cations in other layers. In this sense, we do not directly impose designs from one layer to another, which indicates designs in each layer are only subject to requirements of that layer. The bene ts from this separation include: 1) the requirement model plays as the mediator to connect designs in di erent do- mains, which clearly separate problems and solutions. By using the intermediary requirement model, the many-to-many mapping relationships between designs that are in di erent layers could be simpli ed as one-to-many relationships, which reduce the complexity of the design work and increase the adaptability of the system design. 2) By using the goal models to represent requirements, we can exploit the inherent advantages of the goal-based analytical techniques to facilitate the design work, such as the analysis of requirement satisfaction and alternative selection. As a result, this proposed framework could be used not only for developing new systems, but also for developing systems that are based on legacy systems. If existing designs of a legacy system cannot satisfy requirements imposed by previous layers, the analysis will backtrack to the previous layers and try to nd another alternative.
There are six tasks identi ed in the Fig. 1, which outline the process for deriving an all-round system design. Concretely, the tasks 1,3 and 5 focus on how to derive general requirements and security requirements from upper layers. To this end, mapping mechanisms among layers will be de ned to assist the derivation of requirements. The tasks 2,4 and 6 focus on how to derive secure designs that ful ll both general requirements and security requirements. We intend to carry out risk-based security analysis processes to derive security designs by adopting security patterns. This general analytical process will be customized for each layer according to their domain speci c features. By introducing such a design process we satisfy the research question 3. 4.3
Changes are inevitable for most systems, and these changes must be handled in a way that ensures the continued satisfaction of system requirements. The essence of our work is to combine concepts in multiple layers, based on which we are able to identify designs in di erent layers which are e ected by change requests.
In front of changed requirements, we will incrementally evolve the system rather than re-design from scratch.
Thus, appropriate strategies should be applied to promote the incremental design process. Referring to the
work[
The expected contribution of this research is providing a systematic means to globally design a secure STS. In this part, we use a simple example to show the ideal system development process. A smart grid real-time pricing scenario is used as an example for illustration. Due to the space limitation, we only focus on a particular part of this example, which is highlighted by dotted rectangles.
Our framework aims to support the secure system design for socio-technical systems, and it is supposed to provide an all-around solution within comparatively e cient processes. To ensure the e ectiveness and e ciency of the proposed framework, we should follow an evaluation methodology to examine the practical value of our work.
Tool support We are intended to develop a CASE tool, which can support all the steps of our analytical framework. Enhanced by this tool, the system design process could be done in a semi-automatic way. For the task 3 and 5, the tool can analyze the designs in upper layers and generate potential requirements, which will be further con rmed and modi ed by human. For task 2, 4 and 6, the tool will assist the security analysis processes to derive security design in each layer. In addition, the tool is able to analyze the ripple-e ects of speci c changes. All the design fragments in uenced by the changes will be presented by the tool, and the customer will take the nal decisions about which part should be changed.
Case study We will apply our design methods to a real socio-technical system, such as smart grid and electrical healthy system. The key point of the case study is to take out the theoretical method from laboratory to practice in order to check whether it works in reality. To this end, a number of factors need to be considered during the case study, such as the background of the method adopter, the time span for learning the method, the help or guide provided by the method designer. We need to exploit the in uential factors as many as possible to provide an in-depth evaluation for our method. In addition, if it is possible we are planning to compare our method with other related work on the same case study to examine the advantages and disadvantages of our method. 6
In summary, satisfaction of the proposed research goals via execution of the described plans will contribute to the state of the art by providing: 1. A conceptual multi-layer framework to understand the secure socio-technical system in a comprehensive way, speci cally to understand the interactions among di erent system components. 2. A methodology to globally design secure socio-technical systems, which satisfy both organizational objectives and security requirements, either based on an existing system or for a new system. The methodology is aimed to enable the evolution of system design to manage requested changes, while continuously ful lling organizational objectives and security requirements. 3. A tool that supports all the analytical steps of the proposed methodology. The tool will allow us to carry out an evaluation to examine the practical value of our work.