You are currently viewing a new version of our website. To view the old version click .
MDPIMDPI
Search all articles
Applied Sciences
Download PDF
  • Article
  • Open Access

4 January 2020

An Approach to Analyze Vulnerability of Information Flow in Software Architecture

,
,
and
1
The Key Laboratory on Reliability and Environmental Engineering Technology, Beihang University, Beijing 100191, China
2
School of Reliability and Systems Engineering, Beihang University, Beijing 100191, China
3
China Academy of Electronics and Information Technology, China Electronics Technology Group Corporation, Beijing 100041, China
*
Author to whom correspondence should be addressed.
Appl. Sci.2020, 10(1), 393;https://doi.org/10.3390/app10010393
This article belongs to the Section Computing and Artificial Intelligence
Version Notes
Order Reprints
Review Reports

Abstract

Current research on software vulnerability analysis mostly focus on source codes or executable programs. But these methods can only be applied after software is completely developed when source codes are available. This may lead to high costs and tremendous difficulties in software revision. On the other hand, as an important product of software design phase, architecture can depict not only the static structure of software, but also the information flow due to interaction of components. Architecture is crucial in determining the quality of software. As a result, by locating the architecture-level information flow that violates security policies, vulnerabilities can be found and fixed in the early phase of software development cycle when revision is easier with lower cost. In this paper, an approach for analyzing information flow vulnerability in software architecture is proposed. First, the concept of information flow vulnerability in software architecture is elaborated. Corresponding security policies are proposed. Then, a method for constructing service invocation diagrams based on graph theory is proposed, which can depict information flow in software architecture. Moreover, an algorithm for vulnerability determination is designed to locate architecture-level vulnerabilities. Finally, a case study is provided, which verifies the effectiveness and feasibility of the proposed methods.

1. Introduction

Due to the increasing complexity of software systems, designers tend to focus on the design and implementation of functional requirements. Non-functional requirements are often neglected, such as security [1]. So, vulnerabilities are inevitably introduced in design phase. In essence, software vulnerabilities are a special kind of defects. They are the manifestations of errors that violate security policies, which exist in every phase of the software life cycle, including requirement analysis, design, coding, testing and operation phases. Such vulnerabilities are the root causes of software security problems [2]. If these vulnerabilities cannot be discovered in time and reside in software until later phases of software development cycle, the normal operation of software systems will be faced with great threats. Software vulnerability analysis is the general term for techniques of locating vulnerabilities, and analyzing their production mechanism and action modes [3,4,5]. It is an important research area in cyber security.
However, although current approaches on software vulnerability analysis can be used for identifying software vulnerabilities, they are mostly targeted at source code and executable programs. These methods can only be applied after the coding phase, when source code and executable programs are available. According to statistical data, about 50%–75% of defects are introduced during the design phase [6], and the repair cost will increase with the delay of discovery time of these defects. As a result, current methods on software vulnerability analysis targeted at source code and executable programs have the following shortcomings: (1) delay of time in discovering vulnerabilities; (2) difficulty fixing these vulnerabilities; (3) high cost in revision.
As the major product of the design phase, software architecture is composed of components and interactions between components [7]. Software architecture can be used to depict not only the static structure of the software, but also the information flow and propagation resulting from component interactions. It is a high-level abstraction of a software system [8]. The architecture defines functional, allocated, and product baselines of a system [9]. It can also be used to track current and future descriptions of a system composed of components and their interconnections, the actions or activities those components perform, and the rules or constraints for those activities [10]. Software architecture plays a crucial role in determining software quality [11].
Analyzing and evaluating software architecture during the design phase has been proved to be an effective way to find potential problems in the early stages of software life cycle, reduce costs and assure software quality [12]. Guided by this idea, some researchers have conducted research on architecture-level security analysis and design [13,14,15,16,17,18,19]. These methods can be used for verifying whether the design of software architecture has met the security requirements, or assuring the security of software architecture by designing security policies that constrain the components, connectors and configurations. However, none of these methods can be used for directly locating vulnerabilities in software architecture.
As a result, by conducting vulnerability analysis for software architectures that only focus on functional requirements but neglect non-functional requirements, and locating the information flow and propagation that violates security policies at design phase, can help find and fix these problems and prevent these vulnerabilities from residing until later phases. Locating the architecture-level information flow and propagation that violate security policies enables us to fix these vulnerabilities as early as possible, avoiding the possibility for them to reside until later phases of software development cycle. Some researchers have proposed that it is necessary to analyze software vulnerability on the architecture level [20,21], but what they propose is only the belief and necessity for architecture-level vulnerability analysis, lacking the description of the meaning of software architecture vulnerability as well as feasible or practical approaches.
As a result, this paper provides a graph-theory-based approach to analyze information flow vulnerabilities in software architecture. The key contribution of this paper is to provide an architecture-level vulnerability analysis method by examining the information flow between components. The proposed method can be used for directly locating architecture-level vulnerabilities.
In detail, first, the concept of information vulnerability in software architecture is proposed. This concept complements and improves current theory of software vulnerability in design phase. Second, based on Bell–LaPadula model and Biba model, the policies for determining information flow vulnerability in software architecture are proposed. The proposed policies are extensions of Bell–LaPadula model and Biba model to architecture level. These policies constrain the direction of information flow. Third, a graph-theory based modeling method is proposed. The constructed service invocation diagram model can be used to depict the information flow and propagation in architecture, with consideration of security levels of each node and operation types between nodes. Fourth, an algorithm for locating information flow vulnerabilities in software architecture is proposed.
The rest of the paper is organized as follows: In Section 2, related works are analyzed. The proposed method is elaborated in Section 3. Section 4 presents a case study. Conclusions and future work are given in Section 5.

3. Proposed Approach

3.1. Assumptions and Framework of the Proposed Method

Assumption 1.
The understanding of software architecture in this paper is based on [7]. Software architecture is composed of components and interactions between components. In modelling software architecture, we borrow the concepts from service-oriented architecture (SOA), which is widely used in both software engineering and systems engineering. In SOA, each service is an independent function unit composed of a single component or several components [54]. So, the software architecture in this paper is viewed as a composition of services and interactions between services.
Assumption 2.
As mentioned in the Introduction section, designers tend to focus on the design and implementation of functional requirements, while non-functional requirements tend to be neglected [1]. Hence, the second assumption is that the architectures that this paper focuses on are designed without considering non-functional requirements, especially security requirements. So, these architectures only reflect functional-level information flow and propagation.
Assumption 3.
The types of service invocation operation are limited to reading and writing. While in software engineering, there are three types of operations—Reading, writing, and execution. The execution operation is not considered in this paper, because execution operations occur in source code level or executable program level [55]. Execution operation is not suitable for architecture level.
In this paper, we first propose a definition and formal description of information flow vulnerability in software architecture. Then, security policies of information flow in architecture are given based on Bell–LaPadula model and Biba model. After that, the construction method for service invocation diagram of software architecture is proposed based on graph theory. Finally, we designed and implemented a corresponding algorithm for locating vulnerabilities. The framework of the research method is shown in Figure 1, where green blocks represent background and domain knowledge needed in this research, rounded rectangles represent research that needed to be conducted, blue rectangles represent the results and outputs of each part of the research, gray rectangles represent the analysis results.
Figure 1. Framework of the proposed approach.

3.2. Vulnerability of Information Flow in Software Architecture

In this subsection, we will propose the concept of vulnerability of information flow in software architecture and corresponding formal description. As mentioned above, software architecture can be used for depicting the information flow and propagation resulting from interactions between components. As a result, before giving the definition of information flow vulnerability in software architecture, we will firstly clarify two concepts, including what is software architecture vulnerability, what is the information flow in architecture.
Definition 1.
Software architecture vulnerability. Software architecture vulnerability is the errors resulting from violations of corresponding security policies by components and interaction between components that forms the software architecture.
Based on this definition, we can further explain and understand the essence of software architecture vulnerability from four aspects. First, the essence of vulnerability is a kind of design errors. Second, the core of software architecture vulnerability is the violation of security policies by architecture design. Third, this definition can help architecture designers and analyzers identify which part of the architecture needs to be protected by an architecture-level security mechanism [2]. Fourth, this definition is a generalization of all kinds of software architecture vulnerabilities. It can be further divided into subcategories, which will not be covered in this paper.
To better differentiate our work from other current work on software vulnerability, we compare software architecture vulnerability with traditional code-level vulnerability, shown in Table 2.
Table 2. Comparison of software architecture vulnerability with code-level vulnerability.
The most significant differences between software architecture and code-level vulnerability are as follows. First, they are of different abstraction granularities. Architecture-level vulnerabilities are at a higher level of abstraction granularity. Besides, objects to be analyzed in architecture-level and code-level vulnerability are different. In architecture-level vulnerability, the software architecture is analyzed. Finally, they have different focuses. Architecture vulnerability analysis focuses on the structural level, such as components, interactions between components and the topology resulting from these interactions while code-level vulnerability analysis focuses on lexical, syntactic and semantic aspects.
Definition 2.
Information flow in architecture. This is the flow and propagation of information of the components, interactions between components and the topology that forms from their interaction. The information in this definition is the same as data.
Based on the understanding of information flow in architecture above, vulnerability of information flow in software architecture is defined as follows:
Definition 3.
Vulnerability of information flow in software architecture. Vulnerability of information flow in software architecture is errors resulting from the violation of corresponding security policies during the flow and propagation of information in components, interactions between components and the topology formed from those interactions.
Normally, the flow and propagation of information should conform to confidentiality and integrity policies [49]. Hence, the manifestation of information flow vulnerability in software architecture can be categorized into vulnerability under confidentiality and integrity policies.
Definition 4.
Vulnerability of information flow in software architecture under confidentiality policies Information carried by the architecture only being allowed to flow inside services at the same security level or from services of low security level to those of high security level. All services and interactions between services violating this principle are vulnerabilities of information flow in architecture under a confidentiality policy.
This definition can be described based on a lattice as follows:
For software architecture SA, there are confidentiality policy requirements. When { L , ≤ } , A , B ∈ L , if there exists passing of information from A to B, then A ≤ B holds;
If there exists a ∈ A, b ∈ B, and a → b, then a → b is secure;
If there exists a ∈ B, b ∈ A, and a → b, then { a → b } ∈ V s a .
Definition 5.
Vulnerability of information flow in software architecture under integrity policies Information carried by the architecture is only being allowed to flow inside services of the same security level or from services of high security level to those of low security level. All services and interactions between services violating this principle are vulnerabilities of information flow in the architecture under integrity policy.
This definition can be described based on lattice as follows:
For software architecture SA, there are integrity policies requirement. When { L , ≥ } and A , B ∈ L , if there exists data passing from A to B, then A ≥   B holds;
If there exists a ∈ A, b ∈ B, and a → b, then a → b is secure;
If there exists a ∈ B, b ∈ A, and a → b, then { a → b } ∈ V s a
In the description above, SA represents the software architecture set, L represents the set of secure classes, ≤ denotes the relationship between low and high secure classes, A and B are elements in L, a represent a service, a ∈ A means a is of security level A. → denotes the direction of information flow between services, and Vsa represents software architecture vulnerability.
To explain Definitions 4 and 5, Figure 2 and Figure 3 are presented. In Figure 2, we can see that the architecture is composed of service 1 to service 5. The rectangular boxes represent services. The color represents the security level of each service, in which blue represents low security level while yellow represents high security level. The boxes with the same color represent services with the same security level. The symbol “→” represents the interaction between services and the direction of data flow. In Figure 2, the part inside the red box is the vulnerability of information flow in software architecture under confidentiality policies.
Figure 2. Graphic example of Definition 4.
Figure 3. Graphic example of Definition 5.
Similarly, in Figure 3, we can see that the architecture is composed of service 1 to service 5. The rectangular boxes represent services. The color represents the security level of each service, in which pink represents high security level while green represents low security level. The boxes with the same color represent services with the same security level. The symbol “→” represents the interaction between services and the direction of data flow. In Figure 3, the part inside the red box is the vulnerability of information flow in software architecture under integrity policies.

3.3. Security Policies of Information Flow in Architecture

In this subsection, we propose security policies of information flow in software architecture based on Bell–LaPadula model and Biba model. These policies specify the direction of information flow in three operations that occur in service interactions, including reading operation, writing operation as well as reading and writing operation.

3.3.1. Security Policies of Information Flow under the Goals of Confidentiality

As mentioned above, the confidentiality policy of information flow is intended to prevent information from flowing to subjects that are not authorized to access the information, that is, information is only allowed to flow inside a security class or from a class with low security level to a class with higher security level. We propose security polices as follows:
Policy 1.
Policy for reading operation in service invocation under the goal of confidentiality.
If there is an invoking service A and an invoked service B, A can perform the reading operation on B if and only if Ca ≥ Cb. The information flow is B → A. Cx stands for the confidentiality level of service x.
Policy 2.
Policy for writing operation in service invocation under the goals of confidentiality.
If there is an invoking service A and an invoked service B, A can perform the writing operation on B if and only if Ca ≤ Cb. The information flow is A → B.
Policy 3.
Policy for reading and writing operation in service invocation under the goals of confidentiality.
If there is an invoking service A and an invoked service B, A can perform both reading and writing operation on B if and only if Ca = Cb. The information flow is A ⇆ B.

3.3.2. Security Policies of Information Flow under the Goals of Integrity

An integrity policy of information flow is intended to prevent information from flowing to subjects or data with a higher integrity level and ensures that information only flows inside a security class or to a class with lower security level. Integrity refers to the feature that information cannot be destroyed, lost, or modified without authorization when it is transmitted, exchanged, stored, or processed. There are two kinds of modification, direct and indirect. Direct modification means service A performs the writing operation on service B, and indirect modification means that service A performs the reading operations on service B. Aiming at reading, writing, as well as reading and writing operations that occur during service invocation, we propose security polices as follows:
Policy 4.
Policy for writing operation in service invocation under the goal of integrity.
If there is an invoking service A and an invoked service B, A can perform the writing operation on B if and only if Ia ≥ Ib. The information flow is A → B. Ix stands for the integrity level of service x.
Policy 5.
Policy for reading operation in service invocation under the goal of integrity.
If there is an invoking service A and an invoked service B, A can perform the reading operation on B if and only if Ia ≤ Ib. The information flow is B → A.
Policy 6.
Policy for reading and writing operation in service invocation under the goal of integrity.
If there is an invoking service A and an invoked service B, A can perform both reading and writing operations on B if and only if Ia = Ib. The information flow is A ⇆ B.

3.4. Construction Approach of Service Invocation Diagram Based on Software Architecture

From Section 3.3, we can see that two key points of security policies of information flow in architecture are the direction of information flow during service invocation and the security class of each service. As a result, the model constructed by the proposed approach should have corresponding descriptive ability. That is, the model should be able to reflect the direction and path of information flow in the architecture as well as the confidentiality and integrity level of the information carried by services. Software architecture design specification contains some diagrams that can reflect information interaction, such as data flow diagrams, flow charts, activity diagrams, and state diagrams, but these diagrams cannot be used for analysis directly. This is because the uncertainty of the future operation environment of the system, the complexity of the software, the cognitive limitation of the designer and service reuse in current service-oriented architectures make it impossible for all potential information flow and propagation to be included in these diagrams. To further explain this problem, we give an example, shown in Figure 4.
Figure 4. Data flow path of (a) architecture design phase vs. (b) data flow path in actual operation.
In the architecture design specification of a piece of software, there is a statement that when performing a certain function, a calculation service X is supposed to pass the calculated value to another service Y. According to this description, a designer designs the information flow path as shown in Figure 4a. However, to achieve this in actual operation of the system, before passing the value to calculation service Y, calculation service X invokes storage service Z. Then Z invokes calculation service z and passes the value to y. From this process, we can see clearly that an implicit information flow X → Z → Y, which does not exist in the design phase, emerges, as shown in Figure 4b.
So, it is not enough to use architecture design specification and architecture diagrams to analyze the vulnerability of information flow in software architecture. It is necessary to construct a model that can capable of depict all potential information flow and propagation based on architecture. In the 18th century, Euler, a renowned mathematician, solved the famous problem of the seven bridges of Konigsberg by abstracting paths into a graph and hence set up graph theory. As a data structure, a graph can represent complex relationships between data elements that cannot be determined intuitively. In this paper, we model the information flow and propagation in architecture by use of graph theory.

3.4.1. Determination and Representation of Service Invocation Elements

There are many relationships between and among services, such as invocation, containment, association, aggregation, cascade, and replacement. In these relationships, invocation is the most capable of reflecting the direction and propagation of the carried information. Before determining the service invocation relationship, we first propose a definition for service invocation and a series of related concepts as the basis for describing the invocation relationship between services.
Definition 6.
Service invocation. Service invocation refers to the process of information carried in one service is passed on to another service.
Definition 7.
Set of service invocations. The set of service invocations is a set consisting of service invocation elements. It can be denoted by a quadruple I. I = {S,R,A,D}, in which S stands for the pair of service involved in the invocation, R represents the invocation relationship, A is the operation sequence of service invocation, and D is the direction of data flow.
The definitions R, A, and D will be given in definitions 8–10.
Before defining the relationship of service invocation R, forms of service invocation should be clarified, including the types of service invocation and forms of service interaction. In serviced-oriented software architecture, there are four types of service invocation: sequence structure, selection structure, parallel structure, and iteration structure [56], as shown in Figure 4. In data flow analysis, it is common to ignore the conditions of the paths, i.e., to assume that all paths are feasible [57]. As a result, based on the four types of service invocation, we can abstract three types of service interaction: one to one, one to many, and many to many. This is also consistent with the interaction relationship between common data elements [58]. Table 3 shows these three types of service interaction.
Table 3. Types of service interaction.
Definition 8.
The relationship of service invocation. The relationship of service invocation refers to the interaction form when service invocation occurs, which can be denoted by a tuple, R = {Ss,So}. Ss stands for the invoking service, which is the service that invokes another service, and So stands for the invoked service, which is the service that is invoked. This tuple can be denoted as Sso. For example, if service i invokes service j, then the relationship of this invocation can be denoted as Sij.
Figure 5 and Table 3 provide examples to show the relationships of the four types of service invocation. For sequence structure, the corresponding type of service interaction is one to one, and the resulting relationship is S12 and S23…, Sn-1Sn. For parallel structure, the corresponding types of service interactions are one to many and many to one, and the resulting relationship are S1S2, S2S5 AND S1S3, S3S5 AND S1S4, S4S5. For selection structure, the corresponding types of service interaction is one to many and many to one, and the resulting relationship is S1S2, S2S5 OR S1S3, S3S5 OR S1S4, S4S5. For iteration structure, the corresponding type of service interaction is one to one, and the resulting relationship is S1S2 and S2S1.
Figure 5. Types of service invocation.
The service invocation process includes not only interaction types, but also operation sequence of service invocation A and direction of data flow D. Next, the operation sequence of service invocation A and the direction of data flow between services resulting from service invocation process will be defined.
Definition 9.
Operation sequence of service invocation. Operation sequence of service invocation refers to the set of operations during service invocation. It can be denoted by a tuple, A = {r, w}, in which r represents reading operation and w represents writing operation.
Definition 10.
Direction of data flow between services. Direction of data flow between services refers to the direction of data flow when reading and writing operation occur during service invocation, which can be denoted by the symbol “→”.
For example, if there exist data Di ∈ Ss, Dj ∈ So, and a set of service invocation I = {Ss,So,r}, then this means invoking service Ss performs the reading operation on invoked service So. The direction of data flow can be represented by So → Ss, which means that when an invoking service performs the reading operation on an invoked service, the data flow from the invoked service to the invoking service. Similarly, if there exists data Di ∈ Ss, Dj ∈ So, and a set of service invocation I = {Ss,So,w}, this means invoking service Ss performs the writing operation on invoked service So. The direction of data flow can be represented by Ss → So, which means that when an invoking service performs the writing operation on an invoked service, the data flow from the invoking service into the invoked service. In addition to performing the reading and writing operations separately, an operation sequence of service invocation can perform both operations concurrently. In this case, the direction of data flow can be explained as follows: If there exists data Di ∈ Ss, Dj ∈ So and a set of service invocation I = {Ss,So,r and w}, it means the invoking service Ss performs both the reading and writing operations on the invoked service So. The direction of data flow can be represented by So → Ss and Ss → So, which means that when an invoking service performs the reading and writing operations concurrently on an invoked service, data flows from the invoked service to the invoking service and from the invoking service into the invoked service at the same time.

3.4.2. Definition and Construction Approach for Service Invocation Diagram

From the research above, the information about service invocation can be obtained. Then by using graph theory, a service invocation diagram can be constructed, which can be used as basis for later vulnerability analysis of information flow in architecture.
To construct a service invocation diagram, we propose mapping rules between service invocation information obtained above and elements in the diagram. First, services are mapped into vertices in the diagram. Second, the invocation relationship is mapped into the edges. Third, the operation type of service invocation is mapped as weights on the edges. The weight value mapping from the reading operation is 1, and the weight value from the writing operation is 2. Moreover, the direction of an edge is based on the direction of data flow between services. As a result, the service invocation diagram constructed in this paper is a weighted and directed graph.
Definition 11.
Service invocation diagram. Service invocation diagram is a data structure used to describe invocation information between services. It consists of a nonempty set of vertices V (composed of n vertices, n > 0) and a set of edges E (relations between vertices), which can be denoted as
G = ( V , E )
After learning the service invocation information and defining the service invocation diagram, we can describe the service invocation diagram by use of an adjacency matrix.
Definition 12.
Adjacency matrix of service invocation diagram. For a service invocation diagram G, a one-dimensional array with n elements L [0, n−1] can be given to describe the information of vertices. Based on this, a two-dimensional array A [0, n−1] [0, n−1] can be given, which is the adjacency matrix for this service invocation diagram. In matrix A, the element Aij stores the information relation between vertices i and j. The matrix can be denoted as
A i j   =   { w i j 0
When there exists a relationship between service i and j, then there exists an edge between vertices i and j, the weigh on the edge is w i j . As mentioned above, w i j = 1   o r   2 .
When there is no relationship between services i and service j, the value of w i j is 0.
Finally, by traversing all invocation relations between services, the adjacency matrix and service invocation diagram can be obtained.

3.4.3. Approach for Determining Confidentiality and Integrity Levels of Services

After constructing the service invocation diagram, we need to assign values for the confidentiality and integrity levels of services. The core element for determining the security level of a service is to determine the security level of data carried on that service, that is, to assign values for the confidentiality level and integrity level for that data information. When assigning values, we need to comprehensively consider the confidentiality and integrity levels of the data as well as the security level of services. In this paper we adopt a method for assigning values and determining levels for assets from the security area that are widely accepted [59,60,61] and considered practical. The equations for determining the confidentiality level and integrity level for services are as follows.
S E R c l = R o u n d 1 D c l × S e c l + 1
Equation (1) determines confidentiality level, in which S E R c l represents the confidentiality level of a service, D c l represents the confidentiality level of data carried on that service, which is determined by the criticality level of data confidentiality, S e c l represents the security level of that service, and R o u n d 1 means round up to one decimal. It is worth noting that + 1 in the equation means the confidentiality of the service is higher than that of the data. To simplify, we take 1 for value 1.
S E R i l = R o u n d 1 D i l × S e c l
Equation (2) determines the integrity level for services, in which S E R i l represents the integrity level of a service, D i l represents the integrity level of data carried on that service, which is determined by the criticality level of data integrity, S e c l represents the security level of the service, R o u n d 1 means rounding up to one decimal.
The values of D c l and D i l in Equations (1) and (2) are determined by experts according to Table 4 and Table 5.
Table 4. Criticality level of data confidentiality.
Table 5. Criticality level of data integrity.
As for security level of services in Equations (1) and (2), when the security of the service is compromised, the software system, the user, and the organization to which the service belongs will be impacted. Different entities will suffer from the impacts of different severity levels. In this paper, we define three severity levels: medium, critical, and extreme. As a result, the security levels impacted by objects and severity levels together can be classified into five level, {1,2,3,4,5}. Level 1 means there is almost no impact; level 2 means there are minor impacts; level 3 means there are some medium impacts; level 4 means there are some significant impacts; level 5 means there are critical impacts. Referring to [62], we propose a determination matrix for service security levels, as shown in Table 6. According to this matrix, combined with the characteristics of the software system, and under the guidance of expert experience, the security level of each service can be obtained.
Table 6. Determination matrix for service security level.
Finally, through Equations (1) and (2), the confidentiality and integrity levels of services can be obtained and thus a service invocation diagram based on architecture can be constructed. In the rest of the paper, we will use this model to locate vulnerabilities of information flow in software architecture.

3.5. Algorithm for Detemining Vulnerability of Information Flow in Architecture

There are two major tasks in locating vulnerabilities based on the service invocation diagram: First, find all paths of information flow and propagation. Second, based on the confidentiality or integrity level of each vertex on the paths as well as the direction of information flow between adjacent vertices, locate vulnerabilities by looking for vertices that violate the security policies of information flow proposed above. In this paper, two algorithms are designed to identify and locate vulnerabilities in the service invocation diagram based on confidentiality and integrity policies. Key points of the algorithms are as follows:
  • Use all vertices with an in degree of 0 as initial vertices, and sort them.
  • Find paths that begin with these vertices with an in degree of 0 one by one. Stop until no vertices interact with these vertices. Then output these paths. Although the reading and writing operation (denoted by “r and w”) will cause loops in the diagram, there is no need to iterate these loops when finding paths, because by traversing the loop once, services pairs that violate security policies will be located. So, when finding paths, we only consider the loops once.
  • Use these paths and determination rules under the goals of confidentiality or integrity as input. Compare the confidentiality or integrity levels of two adjacent vertices. For example, if the path is N1, N3, N5, N6, N9, then compare with N1N3, N3N5, N5N6, N6N9, respectively, in which N stands for a node.
  • Save and output the vertices that conflict with determination rules, as well as their interaction relationships, until all vertices of each path are compared.
Algorithm 1 is the algorithm for determining the vulnerability of information flow in architecture under the confidentiality policies. Algorithm 2 is the algorithm for determining the vulnerability of information flow in architecture under the integrity policies.
Algorithm 1 Determining vulnerability under confidentiality policies
1:Input a graph, G; initialize a list of paths allPaths and list of vulnerable nodes vNodes
2:i ← 0
3:for each node n in G do
4: if in-degree of n=0 then
5:  while adjacent node j of node n exists do
6:   i ← FindPath(i,n,n,allPaths)
7:   i ← i+1
8:  end while
9: end if
10:end for
11:for each path p in allPaths do
12: for k ← 0 to p.length-2 do
13:  if security level of p[k]<p[k+1] then
14:   add p[k] in vNodes
15:   add p[k+1] in vNodes
16:  end if
17: end for
18:end for
19:return allPaths and vNodes
20:Function FindPath(num, currentNode, root, allPaths)
21: while adjacent node y of currentNode exists do
22:  add y in allPaths[num]
23:  num ← num+1
24:  for each node z in allPaths[num-1] do
25:   add z in allPaths[num]
26:  end for
27:  num ← FindPath(num, y, root, allPaths)
28: end while
29: return num
Algorithm 2 Determining vulnerability under integrity policies
1:Input a graph, G; initialize a list of paths allPaths and list of vulnerable nodes vNodes
2:i ← 0
3:for each node n in G do
4: if in-degree of n=0 then
5:  while adjacent node j of node n exists do
6:   i ← FindPath(i,n,n,allPaths)
7:   i ← i+1
8:  end while
9: end if
10:end for
11:for each path p in allPaths do
12: for k ← 0 to p.length-2 do
13:  if security level of p[k]>p[k+1] then
14:   add p[k] in vNodes
15:   add p[k+1] in vNodes
16:  end if
17: end for
18:end for
19:return allPaths and vNodes
20:Function FindPath(num, currentNode, root, allPaths)
21: while adjacent node y of currentNode exists do
22:  add y in allPaths[num]
23:  num ← num+1
24:  for each node z in allPaths[num-1] do
25:   add z in allPaths[num]
26:  end for
27:  num ← FindPath(num, y, root, allPaths)
28: end while
29: return num

4. Case Study

4.1. Purpose

In this section, a real-world software architecture was selected as an example. When designing this system, non-functional requirements were neglected. The methods proposed in this paper were used to analyze its architecture. Results were observed to see whether vulnerabilities in the architecture could be located in order to verify the feasibility and effectiveness of the proposed method.

4.2. Introduction of the Object System

The object system used in the case study was a flight reservation system of an airline company. The architecture of the system was service-oriented. Its main functions included user information input and statistics, user information storage, transmission and receipt of ticket information, notice of ticket pick-up, generation and printing of bills, statistics and checking of ticket sales, processing of ticket information based on user needs, generation of flight information, inquiry and feedback of flight information, inquiry and feedback of travel agencies, analysis and management of sales, and so on. To implement these functions, designers classified the system into four major modules: client-side information reception, client-side information output, network reception and dispatch, and server modules. Figure 6 shows the composition of this system. Software designers performed the preliminary design and detailed design and wrote a software architecture design document for this system.
Figure 6. The modules of the flight reservation system.

4.3. Experimental Design and Environment

In this paper, the client-side information reception module was selected as the experimental object to verify the analysis approach for vulnerability of information flow under the goal of confidentiality proposed in this paper. The network reception and dispatch module was selected as the experimental object to verify the analysis approach for vulnerability of information flow under the goal of integrity. The experiment was conducted on a computer installed with Ubuntu 19.04, PyCharm IDE, and an assisted modelling tool called Graphviz.

4.4. Experimental Process

Step 1. We used the architecture design document to determine and describe the services included in the client-side information reception module and network reception and dispatch module. The service composition of these two modules, the functions of these services, and the process to realize the whole module are shown in Appendix A and Appendix B.
Step 2. According to Appendix A and Appendix B and following the methods proposed in Section 3.4, we analyzed the client-side information reception module and network reception and dispatch module to obtain their service invocation elements and the confidentiality or integrity level of each service. The service invocation elements and confidentiality levels of each service in the client-side information reception module are shown in Table 7 and Table 8. The service invocation elements and integrity levels of each service in the network reception and dispatch module are shown in Table 9 and Table 10.
Table 7. Service invocation elements in client-side information reception module.
Table 8. Confidentiality values of each service invocation element in client-side information reception module.
Table 9. Service invocation elements in network reception and dispatch module.
Table 10. Integrity values of service invocation elements in network reception and dispatch module.
Step 3. Based on the obtained service invocation information above, the service invocation diagram was constructed. Then, we used Graphviz to visualize the service invocation diagrams for client-side information reception and network reception and dispatch modules, as shown in Figure 7 and Figure 8, respectively. In these figures, the value 1 on the edge stands for a reading operation, while 2 stands for a writing operation.
Figure 7. Service invocation diagram of client-side information reception module.
Figure 8. Service invocation diagram of network reception and dispatch module.
Step 4. We used the two algorithms for determining the vulnerability of information flow in architecture proposed in this paper to locate vulnerabilities in the client-side information reception module and network reception and dispatch module. We developed a program which implemented these two algorithms and used the program to obtain the analysis results.

4.5. Result Analysis and Threats to Validity

4.5.1. Results

The results were obtained as follows.
For the client-side information reception module, we applied the algorithm for determining the vulnerability of information flow in architecture under the goal of confidentiality. The results are shown in Figure 9.
Figure 9. Output of vulnerability determination algorithm under the goal of confidentiality.
Paths containing vulnerabilities were obtained:
P4: S0 → S1 → S7 → S0; P6: S0 → S4 → S7 → S0.
The corresponding vulnerability information is S7 → S0. The reason for why this is vulnerable will be discussed in detail in Section 4.5.2.
For the network reception and dispatch module, we applied the algorithm for determining the vulnerability of information flow in architecture under the goal of integrity. The results are shown in Figure 10.
Figure 10. Output of vulnerability determination algorithm under the goal of integrity.
Paths containing vulnerabilities were obtained:
P3: S0 → S1 → S2 → S3 → S10 → S9 → S10 → S3 → S4 → S5 → S12;
P4: S0 → S1 → S2 → S3 → S10 → S3 → S4 → S5 → S12;
P5: S0 → S1 → S2 → S3 → S10 → S9 → S10 → S11;
P8: S0 → S1 → S6 → S7 → S8 → S9 → S10 → S3 → S4 → S5 → S12
along with the corresponding vulnerability information:
S10 → S3 and S10 → S9.
The reason for why this is vulnerable will be discussed in detail in Section 4.5.2.

4.5.2. Results Analysis and Discussion

From the results of the vulnerability analysis of information flow in architecture under the goal of confidentiality conducted in the case, it can be seen that the vulnerability was S7 → S0 (detailed descriptions of S7 and S0 are provided in Appendix A), which violated the first security policy of information flow under this goal. By analyzing the architecture design specifications with the help of domain experts, we learned that when verification service returned an error value to the login service, user and ticket information could be leaked, which could cause leakage of users’ private information such as name and itinerary. In addition, malicious attackers could use this vulnerability to try logging in to the system, for example by inputting erroneous information on purpose, and obtain return values of the system, which could be used to guess users’ passwords. If the login succeeded, they could imitate users to modify ticket information or conduct other operations in the system. According to the analysis above, we provided this feedback on architecture vulnerability to the developers and suggested that they modify the architecture. Specifically, we suggested that the developers bind the verification service with a login service in order to make sure that users’ identities can be verified when they attempt to login, rather than after their information is saved, as in this system.
From the result of the vulnerability analysis of information flow in architecture under the goal of integrity conducted in the case study, it can be seen that the vulnerabilities were S10 → S3 and S10 → S9 (detailed descriptions of S3, S9 and S10 are provided in Appendix B), which violated the fourth security policy of information flow under the goal of integrity. By analyzing the architecture design specifications, we learned that S10 was a monitoring service that could monitor and intervene in S3 and S9 by collecting their runtime information. However, in the design specifications, it was not stated clearly that S10 needed a specific transmission protocol such as virtual private network (VPN) to transfer data, nor was an encryption mechanism mentioned for data receipt and sending. What is worse, there was no permission or access control mechanism for the monitoring service. As a result, in operation, malicious attackers could modify, intercept, or delete data in S3 and S9 by attacking the monitoring service. This analysis result conforms to the reality that most software systems nowadays, especially complex software systems have integrated monitoring services, and because of the complex functional, performance, and accuracy requirement of the monitoring function, many designers tend to neglect security requirements when implementing the monitoring function, which could pose significant threats to the operation of software systems [63]. According to the analysis above, we provided feedback on these vulnerabilities to the developers and suggested that they modify the architecture. For example, we suggested employing VPN and data encryption for data transfer between the monitoring service and the main system, and the monitor service should not have operation privileges for the system.
To further demonstrate the effectiveness of the proposed method, we compare the vulnerability analysis results with common security vulnerabilities from famous vulnerability databases, including Common Vulnerabilities and Exposures (CVE), Open Web Application Security project (OWAP), and National Vulnerability Database (NVD). Common categories of vulnerabilities in these databases are listed in Table 11.
Table 11. Common categories of vulnerabilities in Common Vulnerabilities and Exposures (CVE), Open Web Application Security (OWAP). and National Vulnerability Database (NVD).
In Table 11, we marked four categories of vulnerabilities in Italic form. The vulnerabilities from the results of the case study belong to these four categories.
Besides, we learned from recent news that there are security vulnerabilities in Amadeus flight booking system [64]. The attacker just needs to know the victim’s passenger name record (PNR) number to exploit the vulnerability. By using the booking information (i.e., booking ID and last name of the customer) it is possible to access the user’s account and perform other operations. What is worse, the user formation is transmitted without encryption in Amadeus system, which may draw man-in-the-middle attack. It can be seen that the vulnerabilities in Amadeus system are similar to the analysis results in our case study, which further verify the effectiveness of our proposed methods.

4.5.3. Comparison with Other Methods

In previous subsections, we demonstrated the feasibility and effectiveness of the proposed method. To further show the advantages of our method over existing methods, we compare our method with others.
As mentioned in the Introduction, the major contribution of this paper is that we propose a method for locating vulnerabilities in software architecture in the design phase, so the comparison with other methods is also based on this perspective. The comparison results are shown in Table 12.
Table 12. Comparison with other methods.
From Table 12, it can be seen that compared with the method in [25], our method can be used to locate architecture vulnerabilities, while that one cannot. The method in [26] can be used to locate vulnerabilities in architecture. However, the architecture in that method must be obtained after the software development is finished, because in that vulnerability locating method, the architecture of the developed software must be compared with the original version of the software architecture. Then, by injecting malicious source code, vulnerabilities can finally be discovered. As a result, that method cannot be applied in the design phase. The concept of architecture vulnerability is mentioned in [27], but the object of the case study was the source code and vulnerabilities were not located at all.

4.5.4. Threats to Validity

There are some risks and threats to validity, include the following:
  • When assigning values for service confidentiality or integrity, although the assigning method proposed in this paper is based on widely accepted method in cyber security, such as CC (ISO/IEC Standard 15,408) [60] and ISO/IEC Standard 27,000 [59], in a specific assigning activity the method may be impacted by the domain knowledge and experience of researchers, as well as by whether the object system is thoroughly understood. So, when assigning values in this paper, in addition to researchers who possess domain knowledge, we also consulted experienced practitioners and invited them to discuss and confirm the value-assigning results. As a result, to some extent, there might be some subjectivity in the assigning results, but the correctness of the proposed method can be guaranteed.
  • The outputs of the proposed vulnerability analysis method are the services and interactions between services that violate security policies. Further analysis on the outputs requires domain background and experiences of analyzers. In this paper, we invited domain experts who possess strong background knowledge and domain experience. So, the further analysis on the results in this paper is solid.
  • A modeling approach and corresponding vulnerability analysis method is proposed in this paper, and concrete algorithm are given. However, automatic tools for the proposed work are lacking, which will be taken into consideration in our future work.

5. Conclusions and Future Work

In this paper, we propose an approach for analyzing the vulnerability of information flow in software architecture. First, based on confidentiality and integrity policies of information flow and current definitions of software vulnerability and combining features of software architecture, the concept and formal description of vulnerability of information flow in software architecture are given. We clarify that the vulnerability of information flow in software architecture refers to errors resulting from the violation of corresponding security policies during the flow and propagation of information in components, interactions between components, and the topology formed from those interactions. Moreover, targeting at the reading and writing operations during service interaction, security policies of information flow under the goals of confidentiality and integrity are proposed. Then, we propose an approach for constructing a service invocation diagram based on software architecture to depict the interaction and propagation of information flow in architecture as well as the confidentiality or integrity level of each service. After that, an algorithm is designed to located vulnerabilities of information flow in architecture by traversing all potential paths and comparing these paths with predefined security policies of information flow. Finally, a flight reservation system of an airline company was chosen as a case study. After conducting experiments, we found a vulnerability of information flow in the architecture by using confidentiality policies, which was the possibility of information leakage involving users and tickets when the verification service returns error values to the login service. By using integrity policies, we found two vulnerabilities of information flow in the architecture, concerning integrity hazards of the monitoring service. The monitoring service has unnecessarily high privilege when interacting with the system and there is no encryption mechanism for data read from this monitored system. From the case study, we can see that the proposed approaches can be used to locate vulnerabilities of information flow in architecture, thus the effectiveness and applicability can be verified. The proposed method was compared with other methods, and the results show the advantages of our method.
In the future, we will apply the proposed method to more software systems to further verify its effectiveness and usability and improve it. In addition, we will conduct research on value-assigning methods for confidentiality and integrity of services to remedy the shortcoming of the current method which relies highly on experts’ experience, and improve the accuracy of the assigning method. Moreover, we will extend and complement the proposed modelling method by integrating existing security constrains of the architecture into the model. Finally, corresponding tools will be developed to support the proposed modelling approach and determination algorithms. With the refinement of our method and accumulation of experimental data, we will also consider incorporating machine learning methods from intelligent computing into our work, such as in [65,66]. In addition to the above work, we will also try to apply our research to automotive field, such as autopilot systems. We found several studies on reliability issues in this area [67,68]. As an important quality attribute, security should also be considered in future research.

Author Contributions

Conceptualization, T.G. and L.L.; funding acquisition, M.L.; investigation, T.G.; methodology, T.G., M.L., and L.L.; project administration, M.L.; resources, T.G.; supervision, M.L. and Q.L.; validation, T.G. and L.L.; visualization, T.G. and L.L.; writing—original draft, T.G. and M.L.; writing—review and editing, T.G., M.L., L.L., and Q.L. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded by “National Key Laboratory of Science &Technology on Reliability & Environmental Engineering of China”, grant number “WDZC2019601A303”.

Acknowledgments

The authors would like to thank Zhang Dajian, chief manager at the Testing Center of Finance, China, Chen Qinmin, senior security engineer at the Beijing Certificate Authority, and Zeng Yong, architecture designer expert at the Xiangcao Software Company for their suggestions on value determination in Section 3.4.3 and further analysis on our experiment results in Section 4.5.2.

Conflicts of Interest

The authors declare no conflict of interest.

Appendix A

Appendix A describes services in client-side information reception module.
To implement the major functions of the client-side information reception module, designers performed detailed design and wrote a software design document. According to the software design document, the workflow of the client-side information reception module can be abstracted into the following 12 services. The name and description and each service are shown in Table A1. To ease the modelling process, we numbered these services from 0 to 11.
Table A1. Name and description of each service in client-side information reception module.
Table A1. Name and description of each service in client-side information reception module.
ServiceName and Description
Service S0Entrance service. The starting point of the module.
Service S1PersInfoExam service. Performs preliminary examination for information input in traveler’s information panel. If errors exist, determines the type of error and uses corresponding PErrorType or PErrorRank as parameters to transmit into ErrorHandle service. If no errors exist, transfers to PersInfoInput service.
Service S2PersInfoInput service. After examination without error, transmits data from input datasheet to PersInfoTempSave service.
Service S3PersInfoTempSave service. Receives traveler’s information from PersInfoInput service and saves to a temp file PersInfoTemp.txt. This temp file will be used to verify data transferred from the server and should be deleted after the whole process is complete.
Service S4CheckNoticeExam service. Performs preliminary verification of information input in check and ticket collection panel. If errors exist, determines the type of error and uses corresponding CErrorType or CErrorRank as parameters to transmit to ErrorHandle service. If no errors exist, transfer into CheckNoticeInput service.
Service S5CheckNoticeInput service. After examination without error, transmits data from input datasheet to CheckNoticeTempSave service.
Service S6CheckNoticeTempSave service. Receives traveler’s check and ticket collection information from CheckNoticeInput service and saves to a temp file CheckNoticeTemp.txt. This temp file will be used to verify data transferred from the server and should be deleted after the whole process is complete.
Service S7ErrorHandle service. If errors are found in PersInfoInput or CheckNoticeInput service, transfers to this service. Performs corresponding dealing process and outputs error message.
Service S8OrderCollectDetermination service. Determines whether this operation is ordering or collecting tickets based on the input of PersInfoInput service and set flags. According to the flags, transfers to OrderRequireTrans or CollectRequireTrans service.
Service S9OrderRequireTrans service. Before transferring order requirements, performs hardware and software preparation, for example, prepares ticket ordering information, including traveler’s information, host’s information and so on.
Service S10CollectRequireTran service. Before transfering collecting requirements, performs hardware and software preparation, for example, prepares ticket collecting information, including traveler’s information, host’s information, and so on.
Service S11DataTrans service. Transmits information from client-side to server.

Appendix B

Appendix B describes services in network reception and dispatch module.
To implement the major functions of the network reception and dispatch module, designers performed detailed design and wrote a software design document. According to the software design document, the workflow of the network reception and dispatch module can be abstracted into the following 13 services. The name and description of each service are shown in Table A2. To ease the modelling process, we numbered these services from 0 to 12.
Table A2. Name and description of each service in network reception and dispatch module.
Table A2. Name and description of each service in network reception and dispatch module.
ServiceName and Description
Service S0Entrance service. The starting point of the module.
Service S1NetCheck service. Checks the status of the network. Sends some checking information and receives some feedback information. Checks whether the endpoint to establish a path is valid. If valid, prepares for response, and transfers to RecPre and SendPre service. If not, transfers to NErrorHandle service.
Service S2RecPre service. After NetCheck service checks the network, prepares for receiving data.
Service S3NetReceive service. Receives network packet. When receiving data packets, keeps connection with NetMonitor service. Accepts and returns network data transmission status. According to status information, continues receiving data packets or adjusts correspondingly.
Service S4NetDataReceiveConfirm service. Confirms the acceptance of data transmitted from NetReceive service.
Service S5NetDataUnpack service. Unpacks received data according to specific algorithm.
Service S6SendPre service. After NetCheck service checks the network, prepares for sending data.
Service S7NetDataPack service. Packs data transmitted from server module according to specific algorithm.
Service S8NetDataSendConfirm service. Confirms before sending data to network.
Service S9NetSend service. Sends packed data packets. When sending data packets, keep connection with NetMonitor service. Accepts and returns network data transmission status. According to status information, continues sending data packets or adjusts correspondingly.
Service S10NetMonitor service. From establishment of connection from server to client to completion of data transmission and disconnection, NetMonitor services keeps monitoring network status. Meanwhile, sends status information to NetReceive and NetSend service, and receives status information of data receiving and sending from these two services. If errors occur in the status information, transfers to NErrorHandle service.
Service S11NErrorHandle service. Handles errors in network transmission module.
Service S12JudgeCSFlag service. Based on SetCSFlag in client input or server module, determines which module should receive transfer after network module is completed, client output or server module.

References

  1. Seresht, S.M. A Methodology for Software Requirements Elicitation and Analysis: Semi-Automatic Assistance in Elicitation and Analysis of Textual User Requirements; VDM Verlag: Saarbrücken, Germany, 2009; p. 140. [Google Scholar]
  2. Krsul, I.V. Software Vulnerability Analysis; Purdue University: West Lafayette, IN, USA, 1998. [Google Scholar]
  3. Liu, J.; Su, P.; Yang, M.; He, L.; Zhang, Y.; Zhu, X.; Lin, H. A review on software and network security. J. Softw. 2018, 29, 42–68. [Google Scholar]
  4. Wu, S.; Guo, T.; Dong, G.; Wang, J. Advances in software vulnerability analysis techniques. J. Tsinghua Univ. Sci. Technol. 2012, 52, 1309–1319. [Google Scholar]
  5. Li, Z.; Zhang, J.; Liao, X.; Ma, J. Survey of Software Vulnerability Detection Techniques. Chin. J. Comput. 2015, 38, 718–732. [Google Scholar]
  6. Pressman, R. Software Engineering: A Practitioner’s Approach, 8th ed.; McGraw-Hill: New York, NY, USA, 2014. [Google Scholar]
  7. Sun, C.; Jin, M.; Liu, C. A review of software architecture. J. Softw. 2002, 13, 1228–1237. [Google Scholar]
  8. Shaw, M.; Garlan, D. Software Architecture: Perspectives on an Emerging Discipline; Prentice-Hall, Inc.: Upper Saddle River, NJ, USA, 1996. [Google Scholar]
  9. Raz, A.K.; Kenley, C.R.; DeLaurentis, D.A. System architecting and design space characterization. Syst. Eng. 2018, 21, 227–242. [Google Scholar] [CrossRef]
  10. Sinha, K.; Han, S.Y.; Suh, E.S. Design structure matrix-based modularization approach for complex systems with multiple design constraints. Syst. Eng. 2019. [Google Scholar] [CrossRef]
  11. Gampa, S.; Yazhini, U.S.; Manikandan, N. Methods for evaluating software architecture-A survey. Int. J. Pharm. Technol. 2016, 8, 25720–25733. [Google Scholar]
  12. Zhang, L.; Gao, H.; Wang, S. Software Architecture Evaluation. J. Softw. 2008, 19, 1328–1339. [Google Scholar] [CrossRef]
  13. Jürjens, J. UMLsec: Extending UML for Secure Systems Development. In UML 2002, Proceedings of the 5th International Conference on The Unified Modeling Language, Dresden, Germany, 30 September–4 October 2003; Springer: Berlin/Heidelberg, Germany, 2002; pp. 412–425. [Google Scholar]
  14. Deng, Y.; Wang, J.; Tsai, J.J.; Beznosov, K. An approach for modeling and analysis of security system architectures. IEEE Trans. Knowl. Data Eng. 2003, 15, 1099–1119. [Google Scholar] [CrossRef]
  15. Sharma, V.S.; Trivedi, K.S. Architecture based analysis of performance, reliability and security of software systems. In Proceedings of the International Workshop on Software and Performance, Wosp 2005, Palma, Illes Balears, Spain, 12–14 July 2005; pp. 217–227. [Google Scholar]
  16. Banerjee, S.; Mattmann, C.A.; Medvidovic, N.; Golubchik, L. Leveraging architectural models to inject trust into software systems. In Proceedings of the Workshop on Software Engineering for Secure Systems—Building Trustworthy Applications, St. Louis, MO, USA, 15–16 May 2005; pp. 1–7. [Google Scholar]
  17. Fernandez, E.B. Security Patterns in Practice: Designing Secure Architectures Using Software Patterns; Wiley Publishing: Hoboken, NJ, USA, 2013. [Google Scholar]
  18. Jie, R.; Taylor, R.N.; Dourish, P.; Redmiles, D.F. Towards an architectural treatment of software security: A connector-centric approach. In Proceedings of the SESS 2005 Workshop on Software Engineering for Secure Systems—Building Trustworthy Applications, St. Louis, MO, USA, 15–16 May 2005; pp. 1–7. [Google Scholar]
  19. Shin, M.E.; Malhotra, B.; Gomaa, H.; Kang, T. Connectors for secure software architectures. In Proceedings of the 24th International Conference on Software Engineering and Knowledge Engineering(SEKE 2012), San Francisco, CA, USA, 1–3 July 2012; pp. 394–399. [Google Scholar]
  20. Kazman, R.; Woody, C. Identifying the Architectural Roots of Vulnerabilities. Available online: https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=451035 (accessed on 4 February 2016).
  21. Painchaud, F. Software Architecture Risk Analysis (SARA): A Methodology to Assess Security Risks in Software Architectures, and an Application. Archit. Defin. Eval. 2013, 115, 1–16. [Google Scholar]
  22. Denning, D.E.R. Cryptography and Data Security; Addison-Wesley Longman Publishing Co., Inc.: Boston, MA, USA, 1982. [Google Scholar]
  23. Bishop, M.; Bailey, D. A Critical Analysis of Vulnerability Taxonomies. Available online: https://www.cs.ucdavis.edu/research/tech-reports/1996/CSE-96-11.pdf (accessed on 29 December 1996).
  24. Pieprzyk, J.; Hardjono, T.; Seberry, J. Fundamentals of Computer Security Technology; Springer: Berlin/Heidelberg, Germany, 1994. [Google Scholar]
  25. Al-Azzani, S.; Bahsoon, R. SecArch: Architecture-level Evaluation and Testing for Security. In Proceedings of the 2012 Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture, Helsinki, Finland, 20–24 August 2012. [Google Scholar]
  26. Karppinen, K.; Lindvall, M.; Yonkwa, L. Detecting Security Vulnerabilities with Software Architecture Analysis Tools. In Proceedings of the 2008 IEEE International Conference on Software Testing Verification and Validation Workshop, Lillehammer, Norway, 9–11 April 2008. [Google Scholar]
  27. Su, J.; Xu, T.; Wang, Y.; Cui, B.; Jiang, L.; Sun, W. Vulnerability analysis of software structure. Acta Electron. Sin. 2009, 37, 2404–2408. [Google Scholar]
  28. Bo, X.; Jiang, J.; Luo, X.; Zhang, Y. Simulation and verification of C4ISR architecture based on UML&OPN. Syst. Eng. Electron. Technol. 2008, 30, 617–676. [Google Scholar]
  29. Xu, Z. Static Analysis of C Program; Institute of Software Chinese Academy of Sciences: Beijing, China, 2009. [Google Scholar]
  30. Larochelle, D.; Evans, D. Statically Detecting Likely Buffer Overflow Vulnerabilities. In Proceedings of the SSYM 2001 10th conference on USENIX Security Symposium, Berkeley, CA, USA, 13 August 2001. [Google Scholar]
  31. Xie, Y.; Chou, A.; Engler, D. ARCHER: Using symbolic, path-sensitive analysis to detect memory access errors. In Proceedings of the European Software Engineering Conference Held Jointly with Acm Sigsoft International Symposium on Foundations of Software Engineering, Helsinki, Finland, 1–5 September 2003. [Google Scholar]
  32. Zhang, D.; Liu, D.; Wang, W.; Lei, J.; Kung, D.; Csallner, C. Testing C Programs for Vulnerability Using Trace-Based Symbolic Execution and Satisfiability Analysis. In Proceedings of the International Conference on Computational Science and Engineering, Vancouver, BC, Canada, 29–31 August 2010. [Google Scholar]
  33. Ganapathy, V.; Jha, S.; Ch, D.; Melski, D.; Vitek, D. Buffer Overrun Detection using Linear Programming and Static Analysis. In Proceedings of the 10th ACM conference on Computer and communications security, Washington, DC, USA, 27–30 October 2003; pp. 345–354. [Google Scholar]
  34. Aiken, A. Constraint-Based Program Analysis; Springer: Berlin/Heidelberg, Germany, 1999; p. 388. [Google Scholar]
  35. Nelson, G. Extended Static Checking for Java. In Proceedings of the International Conference on Mathematics of Program Construction, Marstrand, Sweden, 17–19 June 2002; pp. 22–33. [Google Scholar]
  36. Xie, Y.; Aiken, A. Saturn: A scalable framework for error detection using Boolean satisfiability. ACM Trans. Program. Lang. Syst. 2007, 29, 1–42. [Google Scholar] [CrossRef]
  37. Ahuja, R.K.; Magnanti, T.L.; Orlin, J.B. Network flows—Theory, algorithms and applications. J. Oper. Res. Soc. 1993, 45, 791–796. [Google Scholar]
  38. Garrett, R.K.; Anderson, S.; Baron, N.T.; Moreland, J.D. Managing the interstitials, a System of Systems framework suited for the Ballistic Missile Defense System. Syst. Eng. 2011, 14, 87–109. [Google Scholar] [CrossRef]
  39. Raz, A.K.; DeLaurentis, D.A. A System-of-Systems Perspective on Information Fusion Systems: Architecture Representation and Evaluation. In Proceedings of the AIAA Infotech @ Aerospace, Kissimmee, FL, USA, 5 January 2015. [Google Scholar]
  40. Pan, X.; Jiang, Z.; Yang, Y. Importance degree and recovery policies for components of system of system based on resilience. J. Beihang Univ. 2017, 43, 1717–1720. [Google Scholar]
  41. Zhang, Y.; Rui, K.; Li, R.; Yang, C.; Yi, Y. Resilience-based component importance measures for complex networks. In Proceedings of the 2016 Prognostics and System Health Management Conference (PHM-Chengdu), Chengdu, China, 19–21 October 2016. [Google Scholar]
  42. Akella, R.; Tang, H.; McMillin, B. Analysis of information flow security in cyber–physical systems. Int. J. Crit. Infrastruct. Prot. 2010, 3, 157–173. [Google Scholar] [CrossRef]
  43. Challet, D.; Lombardoni, A. Bug propagation and debugging in asymmetric software structures. Phys. Rev. E 2004, 70, 116–121. [Google Scholar] [CrossRef]
  44. Mohamed, A.; Zulkernine, M. On Failure Propagation in Component-Based Software Systems. In Proceedings of the 2008 QSIC The Eighth International Conference on Quality Software, Oxford, UK, 12–13 August 2008. [Google Scholar]
  45. Wang, J.; Liu, Y.H.; Liu, X.L. Model for Cascading Faults in Complex Software. Chin. J. Comput. 2011, 34, 1138–1147. [Google Scholar] [CrossRef]
  46. Pan, W.; L, B. Software quality measurement based on error propagation analysis in software networks. J. Cent. South Univ. 2012, 43, 4339–4348. [Google Scholar]
  47. Zhang, X.; Lv, T.; Zhang, B. Modeling Complex Collaboration Network for Service-Oriented Software Based on Execution Behaviors. J. Softw. 2016, 27, 231–246. [Google Scholar]
  48. Denning, D.E. A lattice model of secure information flow. Commun. ACM 1976, 19, 236–243. [Google Scholar] [CrossRef]
  49. Wu, Z.Z.; Chen, X.Y.; Yang, Z. Survey on Information Flow Control. J. Softw. 2017, 28, 135–159. [Google Scholar]
  50. Ma, X.; Huang, Y. Dependable computing model based on lattice. J. Commun. 2010, 31, 105–110. [Google Scholar]
  51. Mclean, J.; Schell, R.R.; Brinkley, D.L. Security Models; John Wiley & Sons, Inc.: Hoboken, NJ, USA, 2002. [Google Scholar]
  52. Lapadula, L.J.; Bell, D.E. Secure Computer Systems: A Mathematical Model. Mitre Corp Bedford Mass 1973, 4, 229–263. [Google Scholar]
  53. Biba, K.J. Integrity Considerations for Secure Computer Systems; Purdue University Reports and Papers Archive; Purdue University: West Lafayette, IN, USA, 1977; pp. 1–21. [Google Scholar]
  54. Erl, T. SOA Principles of Service Design; Prentice Hall: Boston, MA, USA, 2007. [Google Scholar]
  55. Bovet, D.; Cesati, M.; Oram, A. Understanding the Linux Kernel, 2nd ed.; O’Reilly & Associates, Inc.: Sebastopol, CA, USA, 2002. [Google Scholar]
  56. Benatallah, B.; Dumas, M.; Fauvet, M.-C.; Rabhi, F.A. Towards Patterns of Web Services Composition. In Patterns and Skeletons for Parallel and Distributed Computing; Rabhi, F.A., Gorlatch, S., Eds.; Springer: London, UK, 2003; pp. 265–296. [Google Scholar] [CrossRef]
  57. Aho, A.V.; Sethi, R.; Ullman, J.D. Compilers Principles, Techniques and Tools; Addison-Wesley Longman Publishing Co., Inc.: Boston, MA, USA, 2008. [Google Scholar]
  58. Tang, F. Data Structures, 2nd ed.; Beihang University Press: Beijing, China, 2005. [Google Scholar]
  59. ISO/IEC. ISO/IEC 27000:2018 Information Technology—Security Techniques—Information Security Management Systems; ISO/IEC: Geneva, Switzerland, 2008. [Google Scholar]
  60. ISO/IEC. ISO/IEC 15408:2009 Information Technology—Security Techniques—Evaluation Criteria for IT; ISO/IEC: Geneva, Switzerland, 2009. [Google Scholar]
  61. IOS/IEC. Information Technology-Security Techniques-Code of Practice for Information Security Management; IOS/IEC: Geneva, Switzerland, 2005. [Google Scholar]
  62. China National Standards. Information Security Technology Classification Guide for Classified Protection of Information System; GB/T 22240-2008; China National Standards; Standardization Administration of China: Beijing China, 2008. [Google Scholar]
  63. Calinescu, R. Emerging Techniques for the Engineering of Self-Adaptive High-Integrity Software; Springer: Berlin/Heidelberg, Germany, 2013; pp. 297–310. [Google Scholar]
  64. Paganini, P. Critical bug in Amadeus Flight Booking System Affects 141 Airlines. Available online: https://securityaffairs.co/wordpress/79972/hacking/amadeus-flight-booking-system-bug.html (accessed on 16 January 2019).
  65. Beruvides, G.; Castaño, F.; Quiza, R.; Haber, R.E. Surface Roughness Modeling and Optimization of Tungsten-copper Alloys in Micro-milling Processes. Measurement 2016, 86, 246–252. [Google Scholar] [CrossRef]
  66. Beruvides, G.; Quiza, R.; del Toro, R.; Castaño, F.; Haber, R.E. Correlation of the holes quality with the force signals in a microdrilling process of a sintered tungsten-copper alloy. Int. J. Precis. Eng. Manuf. 2014, 15, 1801–1808. [Google Scholar] [CrossRef]
  67. Fernando, C.; Stanisław, S.; Alberto, V.; Rodolfo, E.H.; Joanna, K. Sensor Reliability in Cyber-Physical Systems Using Internet-of-Things Data: A Review and Case Study. Remote Sens. 2019, 11, 2252. [Google Scholar]
  68. Fernando, C.; Gerardo, B.; Alberto, V.; Rodolfo, E.H. Self-Tuning Method for Increased Obstacle Detection Reliability Based on Internet of Things LiDAR Sensor Models. Sensors 2018, 18, 1508. [Google Scholar]

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
Download PDF
Reconstruction and Measurement of Irregular Karst Caves Using BLST along the Shield Metro Line
Previous
Optical Trapping, Sizing, and Probing Acoustic Modes of a Small Virus
Next