A fuzzy framework for prioritization and partial selection of security requirements in software projects

Abstract

Resource limitations in software projects rarely allow for the security requirements to be fully realized. As such, Prioritization and Selection (PAS) techniques are used to find an optimal subset of the requirements. Consequently, some of the security requirements will be ignored. But ignoring security requirements may (a) leave some of the security threats unattended and (b) negatively impact the effectiveness of the selected requirements. To mitigate this, we have proposed a fuzzy framework, referred to as Prioritization And Partial Selection (PAPS), that reduces the number of ignored security requirements by allowing for partial satisfaction of those requirements. We achieve this by relaxing the satisfaction conditions of security requirements, when tolerated, based on their priorities specified by a fuzzy inference system. Taking into account the partiality of security in PAPS mitigates the adverse impact of ignoring security requirements and enhances the accuracy of prioritization and selection. Our proposed framework is scalable to a large number of requirements.

Keywords

Security Requirements Partial Selection Fuzzy

1 Introduction

Security requirements, also known as security countermeasures [1, 2], are to enhance the security of software systems [3]. But due to the resource limitations, it is hard to implement the entire set of the identified security requirements [4], that makes it nearly impossible to develop a completely secure system [5]. An efficient prioritization and selection technique is therefore needed to find an optimal subset of the security requirements for a software project [5, 6]. However, there are two major problems with existing Prioritization and Selection (PAS) techniques [7], that limit the practicality of those techniques in real-world software projects. These problems are as follows.

(i) Complexity. The existing techniques used for prioritizing and selecting security requirements are, predominately, human-intensive and require a high number of comparisons (Table A.1). That makes these techniques complex and difficult to adopt in real-world software projects[7, 8]. An example of such complex techniques is Analytic Hierarchy Process (AHP) [7, 9], that has been well recognized as the most promising prioritization and selection technique with respect to providing reliable results [10]. Other variations of AHP such as Fuzzy AHP [11, 12] are also complex as they rely on a high number of comparisons. Ranking-Based techniques (e.g., Bubble Sort and Binary Search Tree), Cumulative Voting, EVOLVE, and Planning Game [13], are other examples of well-recognized prioritization and selection techniques that suffer from the complexityproblem [17].

(ii) Inaccuracy. In software projects, security is either treated as the main priority or it is ignored [14]. This binary (all or none) approach to security has negatively impacted the accuracy of the existing techniques used for prioritizing and selecting security requirements: they either select or ignore security requirements [5] without considering the partiality of those requirements in real-world software (Table A.1). But ignoring security requirements may leave some of the security threats [15] unattended and eventually result in security breaches in software systems. Moreover, ignoring a security requirement may negatively influence the effectiveness of the requirements that rely on it. As such, ignoring security requirements results in cascading security issues in software.

To address these, we have contributed a fuzzy framework referred to as Prioritization and Partial Selection (PAPS). The proposed framework enhances the accuracy of prioritizing and selecting security requirements by taking into account the partiality of security. This is achieved by allowing for partial selection (satisfaction) of the security requirements rather than ignoring them. The proposed framework thus helps reduce the number of ignored security requirements, that will (a) reduce the number of unattended security threats and (b) mitigate the risk of ignoring the dependencies [16, 17] of the requirements. PAPS is scalable to a large number of requirements and allows for prioritization and selection of security requirements with respect to different security goals (objectives) [5].

The proposed framework (PAPS) comprises two major processes as follows. The first process, i.e. Pre Prioritization and Selection (Pre-PAS), includes modeling, description, and analysis of security requirements. The second process, i.e. Prioritization and Selection (PAS), takes the formally described Security Requirement Model (SRM) [18] of a system and its corresponding analysis results as the input and constructs the Security Requirement List (SRL) of the system. A Fuzzy Inference System (FIS) then prioritizes the security requirements in the SRL with respect to different security goals [19, 20]. The FIS infers the linguistic priorities of the requirements based on the prioritization criteria (impact, cost, and technical-ability). The prioritization and selection process in PAPS accounts for the partiality of security in the optimal SRL by RELAX-ing [18, 21] the satisfaction conditions of the security requirements when tolerated. Security requirements then, will be RELAX-ed and (partially) included in the optimal SRL of the system.

2 Related work

Several techniques have been used for prioritizing and selecting software security requirements (Table A.1). Among them, Analytic Hierarchy Process (AHP) has been well recognized as a highly reliable [22] yet complex technique [10]. EVOLVE [23] is another example of complex prioritization techniques [7]. The technique uses evolutionary algorithms to find an optimal subset of the requirements. Ranking-Based techniques such as Bubble Sort, and Binary Search Tree have also demonstrated to be complex for a large number of requirements [7]. Fuzzy AHP [11, 12] suffers from the same problem.

Some of the requirement prioritization and selection techniques involve clients (stakeholders) in the process. A widely used example of such techniques is Planning Game [13], that uses the business value specified by the clients and technical risk specified by the developers for prioritization. The technique, however, does not scale well with a large number of requirements [7, 13]. Win Win is another prioritization technique [24], where software stakeholders express their objectives as win conditions. If everyone concurs, the win conditions become agreements; otherwise, iterations may occur. The difficulty in reaching consensus and inconsistencies in the prioritized requirements has been identified as the major drawbacks of the Win-Win technique [25]. Another example is Cumulative Voting [7], where the stakeholders allocate points to the requirements to specify their priorities [24]. This becomes a tedious task for a high number of requirements or stakeholders. Moreover, cumulative voting is prone to human bias as the stakeholders tend to assign more points to their favorite requirements [24].

However, to the best of our knowledge, none of these prioritization techniques allow for partial selection of security requirements (Table A.1). This is despite the fact that the partiality of security has been widely recognized in Software Engineering (SE) [5]; several works have used fuzzy logic to account for this partiality [26]. Such works have adopted fuzzy logic due to its effectiveness in capturing the imprecision and uncertainty of real-world problems [27, 28]. For instance, fuzzy logic has been effectively used for identifying and modeling security threats in computer systems [26]. Also, fuzzy rule-based systems have been employed to specify the risk associated with a particular software system before its installation [29]. Fuzzy logic has also been employed for carrying out security risk analysis in Cyber systems [26, 30].

3 The running example

To demonstrate the practicality of our proposed PAPS framework, we have used an Online Banking System (OBS) as our running example. Figure 1 demonstrates, at the highest level of abstraction, the main functionality of OBS (money transfer), that can be achieved through either online access to the accounts or transferring via debit card. Also, the main threat to OBS is an unauthorized transfer of money out of the accounts, that can be achieved through either hijacking the server or obtaining access to the accounts. Figure 1 further, shows the vulnerabilities of OBS, that can be exploited by an attacker as well as the countermeasures (security use cases), that mitigate them. An excerpt of the OBS description is given as follows.

Fig.1

The Use Case/ Misuse Case Diagram of OBS (Online Banking System).

OBS is an online banking system, that provides banking services like money transfer over the internet. The bank accounts are alluring targets for criminals. OBS transactions therefore must be protected at all times to minimize financial losses. As such, OBS should be protected against any unauthorized online access as such accesses may result in transferring money of the bank accounts. Hence, OBS protects the internet connection and supports user authentication by checking the username and password of the users. Although an attacker may guess the usernames or passwords, initiatives must be taken to make this as difficult as possible for the attacker. OBS must provide a reasonable assurance that the user accounts are secure. The main threat that concerns OBS is that an attacker transfers money out of the user accounts.

4 Pre-PAS process

The Pre-PAS process (Figure 2) includes modeling, description, and analysis of security requirements. The process starts with developing the Security Requirement Model (SRM) of a system and formally describing it using a goal-based Fuzzy Grammar [31, 32]. Risk analysis will be performed then to identify the cost and technical-ability of each security requirement.

Fig.2

The PAPS Framework.

4.1 Modeling and description

As shown in Figure 2, the security requirement model (SRM) of a system serves as the input of the prioritization and selection process in PAPS and therefore needs to account for the partiality of security. As such, we have used a fuzzy-based security requirement modeling technique (Section 4.1.1), proposed in our earlier work [18], that accounts for partial satisfaction of requirements. We have also made use of a fuzzy-based description technique, presented in [33], to formally describe the SRM of a software system. We have demonstrated the use of these techniques by modeling and describing the security requirements of our running example (OBS).

4.1.1 Modeling security requirements

We use a Goal-Based Modeling Process proposed in our earlier work [18] for modeling security requirements. The process starts with identifying the main assets of a system. Then an initial set of goals will be devised to protect those assets against potential security threats [34]. Such goals are High-Level as they merely reflect the intention of the system to protect its assets without specifying how that can be achieved. The mechanism through which high-level goals are satisfied will be determined by refining those goals to more specific Low-Level goals. The refinement of a goal continues until its satisfaction can be assigned to deliverable security requirements in the security requirement model (SRM) of a system. We use a combination of RELAX [21, 35] and KAOS [36] languages to describe the security goals (requirements) in a SRM. The SRM of our running example (OBS) is shown in Figure 3 and the KAOS descriptions of the goals/requirements are given in Table 1.

Fig.3

The security requirement model (SRM) of the online banking system (OBS). Junction points and their absence denote logical AND and OR respectively.

Table 1

The KAOS descriptions of the security requirements (goals) of OBS

Goal	Description	Requirement	Description
S	maintain OBS security	R ₁	achieve request transaction code
G ₁	avoid transfer money out of account	R ₂	achieve latency examination
G ₂	avoid unauthorized online transfer	R ₃	achieve one-time pad
G ₃	avoid stealing id and password	R ₄	achieve SSL
G ₄	avoid man in the middle	R ₅	achieve password trial limitation
G ₅	avoid guessing id and password	R ₆	achieve password policy
G ₆	avoid dictionary attack	R ₇	achieve password encryption
G ₇	avoid guess password	R ₈	achieve random id
G ₈	avoid guess id	R ₉	achieve CAPTCHA
G ₉	avoid brute forcing	R ₁₀	achieve complex pin
G ₁₀	avoid unauthorized transfer via debit card	R ₁₁	achieve access control
G ₁₁	maintain transfer network security	R ₁₂	achieve redundant server
G ₁₂	avoid hijack server
G ₁₃	maintain service availability

4.1.2 Describing security requirements

As part of the modeling and description process in PAPS, we formally describe the security requirements of a system using a fuzzy-based description technique proposed in our earlier work [33]. In the following, we briefly introduce the main components of this fuzzy-based description technique and apply it to the SRM of our running example (OBS).

i. Goal-Based Fuzzy Grammar (GFG). A GFG is a quintuple GR = (G, R, P, S, μ), where G is a set of security goals, R is a set of security requirements, P is a set of fuzzy derivation rules, and μ denotes the membership function of the derivations. Also, S represents the top-level security goal of the system, that is to maintain the security of the system. For OBS, G = {G₁, . . . , G₁₃}, R = {R₁, . . . , R₁₂}, P = {P₁, . . . , P₂₀} and S=“maintain [OBS] [security]”.

The fuzzy nature of GFGs captures the partiality of security in the SRM of a system. The elements of P ∈ GR are expression of form (1). Where d is the degree of the contribution of sub-goal w to satisfaction of goal r. If r₁, . . . , r_n are fuzzy statements in (G ∪ R) ^*, we call r₁ → r₂ → . . . → r_n a goal derivation chain under the employed GFG.

$μ (r \to w) = d, d \in [0, 1] or μ (r, w) = d$ (1)

ii. Extracting Derivation Rules. Our description technique constructs the GFG of a SRM and identifies its corresponding derivation rules [33]. The degree to which the successor of a rule contributes to the satisfaction of its predecessor (membership value) is determined by the membership function μ of a GFG [33]. The derivation rules of the SRM of OBS and their corresponding membership values are listed in Table 2. For instance, derivation rule P₁₁ (G₁ → R₂R₃) states that (a) security goal G₁ derives security requirements R₂ and R₃ and (b) there is a logical AND relation between R₂ and R₃. Therefore, to satisfy G₁ both R₂ and R₃ need to be implemented.

Table 2

Derivation rules for the SRM of OBS

Rule	Membership Value
P₁ : S → G1G₁₃	0.95
P₂ : G₁ → G₂G₁₀G₁₂	0.95
P₃ : G₁₃ → R₁₂	0.9
P₄ : G₂ → R₁G₃G₅	0.85
P₅ : G₁₀ → G₁₁	0.9
P₆ : G₁₀ → R₁₀	0.4
P₇ : G₁₂ → R₁₁	0.9
P₈ : G₃ → G₄	0.85
P₉ : G₅ → G₆G₉	0.9
P₁₀ : G₁₁ → R₉	0.8
P₁₁ : G₄ → R₂R₃	0.75
P₁₂ : G₄ → R₄	0.9
P₁₃ : G₆ → G₇	0.6
P₁₄ : G₆ → G₈	0.6
P₁₅ : G9 → G₇	0.65
P₁₆ : G₉ → G₈	0.6
P₁₇ : G₇ → R₅	0.7
P₁₈ : G₇ → R₆	0.8
P₁₉ : G₇ → R₇	0.9
P₂₀ : G₈ → R₈	0.6

4.2 Risk analysis

During a risk analysis, the cost and technical-ability of the security requirements will be identified and modeled. Conventional risk analysis techniques [37 –39] can be used for this purpose.

Implementation Cost. Budget limitations in a software project may not allow for a complete implementation of the security requirements. As such, we need to consider the implementation cost of the requirements when prioritizing and selecting them [40]. Table 3 has listed the costs of the security requirements of OBS, scaled into [0, 1].

Table 3
Cost and Technical-ability of OBS requirements

Requirement R ₁ R ₂ R ₃ R ₄ R ₅ R ₆ R ₇ R ₈ R ₉ R ₁₀ R ₁₁ R ₁₂

Cost 0.5 0.7 0.7 0.3 0.05 0.5 0.2 0.01 0.6 0.1 0.7 1.0

Technical-ability 1.0 0.2 0.1 0.9 1.0 0.3 0.2 1.0 0.1 1.0 0.2 0.2

Requirement	R ₁	R ₂	R ₃	R ₄	R ₅	R ₆	R ₇	R ₈	R ₉	R ₁₀	R ₁₁	R ₁₂
Cost	0.5	0.7	0.7	0.3	0.05	0.5	0.2	0.01	0.6	0.1	0.7	1.0
Technical-ability	1.0	0.2	0.1	0.9	1.0	0.3	0.2	1.0	0.1	1.0	0.2	0.2

Technical-ability. For a security requirement R_i, Technical-ability is defined as a real number θ_i ∈ [0, 1], which reflects the ease of implementation. Technical-ability of the security requirements of OBS are calculated based on (2) as listed in Table 3.

$θ_{i} = (TechnicalComplexity of R_{i})^{- 1}$ (2)

5 Prioritization and selection process

The prioritization and selection process in PAPS starts with preprocessing the prioritization criteria (impact, cost, and technical-ability) and constructing the Security Requirement List (SRL) of a system, that serves as the input of the Fuzzification [41] process (Figure 2). Fuzzification maps the prioritization criteria to their corresponding linguistic values, that serve as the main inputs of the fuzzy inference system (FIS).

PAPS uses fuzzy inference [42] to identify the linguistic priorities of the security requirements with respect to different security goals in the SRL of a system. These priorities will be defuzzified to RELAX the satisfaction conditions of the security requirements when tolerated and allow for their partial selection. The RELAX-ed requirements then, will be listed in the optimal SRL of the system.

5.1 Data preprocessing

Data preprocessing in PAPS aims to prepare the inputs of the fuzzification process, thus enabling fuzzy inference (Figure 2). In doing so, a security requirement list (SRL) will be constructed that contains the attributes of the security requirements (cost, technical-ability, and impact), used as prioritization criteria in PAPS. Preprocessing, especially, focuses on computing the impacts of the requirements with respect to the security goals and reflecting that in the SRL.

5.1.1 Constructing a security requirement list

Let GR = (G, R, P, S, μ) be the goal-based fuzzy grammar of a system; we have SRL [g] ⊆ R^*, where SRL [g] gives the security requirements that contribute to the satisfaction of goal g ∈ G. In other words, a requirement x is in SRL [g] if and only if it can be derived from g (g → . . . → x). SRL [g] will be constructed for any goal g in the security requirement model of a system. This allows for prioritizing security requirements with respect to different security goals. Function “BuildSRL” in Figure B.1 constructs the SRL of a system. We have implemented the SRL as a two-dimensional list (list of lists) in which a list SRL [g] contains the security requirements which contribute to the satisfaction of goal g.

5.1.2 Calculating the impacts

The impact of a security requirement x in SRL [g] is the degree to which x contributes to the satisfaction of goal g. For a derivation chain g → . . . → x, (3) calculates the impact of x by evaluating the membership values of the derivation rules on the chain and finding the minimum of those values: μ (g, r₁) ⊗ μ (r₁, r₂) ⊗ . . . ⊗ μ (r_n, x). The overall impact of x on g is calculated by finding the maximum impact of x over all alternative derivation chains from g to x: ⊕ (μ (g, r₁) ⊗ μ (r₁, r₂) ⊗ . . . ⊗ μ (r_n, x)). T-norm sign ⊕ and t-conorm sign ⊗ denote fuzzy OR (maximum) and AND (minimum) operators respectively [43]. μ_g(x) specifies the strongest degree of contribution of x to the satisfaction of goal g.

$μ_{g} (x) = \oplus (μ (g, r_{1}) \otimes μ (r_{1}, r_{2}) \otimes . . . \otimes μ (r_{n}, x))$ (3)

As one example, in the SRM of OBS, μ_S (R₇) is computed for two derivation chains: 1) S → G₁ → G₂ → G₅ → G₉ → G₇ → R₇ and 2) S → G₁ → G₂ → G₅ → G₆ → G₇ → R₇, as follows: μ_S (X = R₇) = (0.95 ⊗ 0.95 ⊗ 0.85 ⊗ 0.9 ⊗ 0.65 ⊗ 0.9) ⊕ (0.95 ⊗ 0.95 ⊗ 0.85 ⊗ 0.9 ⊗ 0.6 ⊗ 0.9) =0.65. The impacts of the security requirements in the SRM of OBS are computed by function “CalculateImpact" in Figure B.1 and listed in Table 4.

Table 4

The impacts of the security requirements in the SRM of OBS

Goal	μ (R₁)	μ (R₂)	μ (R₃)	μ (R₄)	μ (R₅)	μ (R₆)	μ (R₇)	μ (R₈)	μ (R₉)	μ (R₁₀)	μ (R₁₁)	μ (R₁₂)
S	0.85	0.75	0.75	0.85	0.65	0.65	0.65	0.6	0.8	0.4	0.9	0.9
G ₁	0.85	0.75	0.75	0.85	0.65	0.65	0.65	0.6	0.8	0.4	0.9	0
G ₂	0.85	0.75	0.75	0.85	0.65	0.65	0.65	0.6	0	0	0	0
G ₃	0	0.75	0.75	0.85	0	0	0	0	0	0	0	0
G ₄	0	0.75	0.75	0.9	0	0	0	0	0	0	0	0
G ₅	0	0	0	0	0.65	0.65	0.65	0.6	0	0	0	0
G ₆	0	0	0	0	0.6	0.6	0.6	0.6	0	0	0	0
G ₇	0	0	0	0	0.7	0.8	0.9	0	0	0	0	0
G ₈	0	0	0	0	0	0	0	0.6	0	0	0	0
G ₉	0	0	0	0	0.65	0.65	0.65	0.65	0	0	0	0
G ₁₀	0	0	0	0	0	0	0	0	0.8	0.4	0	0
G ₁₁	0	0	0	0	0	0	0	0	0.8	0	0	0
G ₁₂	0	0	0	0	0	0	0	0	0	0	0.9	0
G ₁₃	0	0	0	0	0	0	0	0	0	0	0	0.9

5.2 Prioritization

Prioritization in PAPS starts with fuzzifying [19] the prioritization criteria (impact, cost, and technical-ability) of the security requirements, that serve as the input of the fuzzy inference system (FIS) (Figure 2). The FIS then infers the linguistic priorities of the security requirements based on the fuzzy rule-base of PAPS. The priority of a requirement specifies the extent to which it needs to be satisfied.

5.2.1 Fuzzification

Fuzzification in PAPS aims to map the crisp values assigned to the prioritization criteria (impact, cost, and technical-ability) of the requirements to their corresponding categories: Low (L), Medium (M), and High (H). To do so, three membership functions are defined for each input and its related categories. We have employed a semi-trapezoids shape [44] for the membership functions; four diverse points are required to define each membership function (Figure 4). The membership functions are defined by (4) and listed in Table 5. Each membership function will be calculated based on four specific points as depicted equation (4) and Figure B.1. We have implemented the membership functions using Fuzzy Control Language (FCL) [43] and jFuzzyLogic [45].

Table 5
Membership Functions of the FIS Inputs (Output)

FIS Input/ Output Membership Function (μ_iv (x))

Impact (i) $μ_{il} (i) = Max (Min (\frac{i + 0.35}{0.35}, 1, \frac{0.45 - i}{0.35}), 0)$

$μ_{im} (i) = Max (Min (\frac{i - 0.2}{0.25}, 1, \frac{0.55 - i}{0.25}), 0)$

$μ_{ih} (i) = Max (Min (\frac{i - 0.5}{0.1}, 1, \frac{1 - i}{0.1}), 0)$

Cost(c) $μ_{cl} (c) = Max (Min (\frac{i + 0.35}{0.35}, 1, \frac{0.45 - i}{0.35}), 0)$

$μ_{cm} (c) = Max (Min (\frac{i - 0.2}{0.25}, 1, \frac{0.55 - i}{0.25}), 0)$

$μ_{ch} (c) = Max (Min (\frac{i - 0.5}{0.1}, 1, \frac{1 - i}{0.1}), 0)$

Technical-ability (t) $μ_{tl} (t) = Max (Min (\frac{i + 0.35}{0.35}, 1, \frac{0.45 - i}{0.35}), 0)$

$μ_{tm} (t) = Max (Min (\frac{i - 0.2}{0.25}, 1, \frac{0.55 - i}{0.25}), 0)$

$μ_{th} (t) = Max (Min (\frac{i - 0.5}{0.1}, 1, \frac{1 - i}{0.1}), 0)$

Priority (p) $μ_{po} (p) = Max (Min (\frac{p + 0.1}{0.1}, 1, \frac{0.3 - p}{0.1}), 0)$

$μ_{pw} (p) = Max (Min (\frac{p - 0.2}{0.1}, 1, \frac{0.5 - p}{0.1}), 0)$

$μ_{pn} (p) = Max (Min (\frac{p - 0.3}{0.15}, 1, \frac{0.8 - p}{0.15}), 0)$

$μ_{ps} (p) = Max (Min (\frac{p - 0.65}{0.1}, 1, \frac{1 - p}{0.1}), 0)$

FIS Input/ Output	Membership Function (μ_iv (x))
Impact (i)	$μ_{il} (i) = Max (Min (\frac{i + 0.35}{0.35}, 1, \frac{0.45 - i}{0.35}), 0)$
	$μ_{im} (i) = Max (Min (\frac{i - 0.2}{0.25}, 1, \frac{0.55 - i}{0.25}), 0)$
	$μ_{ih} (i) = Max (Min (\frac{i - 0.5}{0.1}, 1, \frac{1 - i}{0.1}), 0)$
Cost(c)	$μ_{cl} (c) = Max (Min (\frac{i + 0.35}{0.35}, 1, \frac{0.45 - i}{0.35}), 0)$
	$μ_{cm} (c) = Max (Min (\frac{i - 0.2}{0.25}, 1, \frac{0.55 - i}{0.25}), 0)$
	$μ_{ch} (c) = Max (Min (\frac{i - 0.5}{0.1}, 1, \frac{1 - i}{0.1}), 0)$
Technical-ability (t)	$μ_{tl} (t) = Max (Min (\frac{i + 0.35}{0.35}, 1, \frac{0.45 - i}{0.35}), 0)$
	$μ_{tm} (t) = Max (Min (\frac{i - 0.2}{0.25}, 1, \frac{0.55 - i}{0.25}), 0)$
	$μ_{th} (t) = Max (Min (\frac{i - 0.5}{0.1}, 1, \frac{1 - i}{0.1}), 0)$
Priority (p)	$μ_{po} (p) = Max (Min (\frac{p + 0.1}{0.1}, 1, \frac{0.3 - p}{0.1}), 0)$
	$μ_{pw} (p) = Max (Min (\frac{p - 0.2}{0.1}, 1, \frac{0.5 - p}{0.1}), 0)$
	$μ_{pn} (p) = Max (Min (\frac{p - 0.3}{0.15}, 1, \frac{0.8 - p}{0.15}), 0)$
	$μ_{ps} (p) = Max (Min (\frac{p - 0.65}{0.1}, 1, \frac{1 - p}{0.1}), 0)$

$\forall i \in {impact, cost, technical - ability},$ (4) $\begin{matrix} \forall v \in {low, medium, high} : \exists (x_{0}, x_{1}, x_{2}, x_{3}), \\ μ (x_{0}) = μ (x_{3}) = 0, μ (x_{1}) = μ (x_{2}) = 1 \to \\ μ_{iv} (x) = max (min (\frac{x - x_{0}}{x_{1} - x_{0}}, 1, \frac{x_{3} - x}{x_{3} - x_{2}}), 0) . \end{matrix}$

Fig.4

Example of a membership function μ_iv.

For a requirement r in the security requirement list (SRL) of a security goal g, function “PrioritizationAndSelection” in Figure B.2 fuzzifies the prioritization criteria of r (SRL [g] [r] . impact, SRL [g] [r] . cost, and SRL [g] [r] . technicalAbility) using the membership functions in Table 5.

5.2.2 Fuzzy inference

Our proposed PAPS framework uses Mamdani-type fuzzy inference [46 –48] to specify the linguistic priorities of the security requirements based on their prioritization criteria (cost, impact, and technical-ability). A fuzzy inference system (FIS) is used for this purpose. Using a fuzzy-rule base, the FIS prioritizes the security requirements under four distinct categories: Optional (O), Weak (W), Normal (N), and Strong (S), as shown in Figure B.2. We have implemented the fuzzy inference rules using fuzzy control language (FCL) as discussed earlier. The inference rules can be modified to reflect the organizational and technical preferences of the stakeholders.

As depicted in Table 6, 27 fuzzy rules are listed in the rule-base of the system. The FIS has used these rules to prioritize the security requirements of the running example (OBS) as listed in Table 7. Each security requirement is assigned 14 different priorities, each of which concerning a specific security goal in the security requirement model of OBS(Figure 3).

Table 6
Fuzzy Rules

Rule Impact Cost Technical-ability Priority

1 l l l o

2 l l m w

3 l l h n

4 l m l o

5 l m m o

6 l m h w

7 l h l o

8 l h m o

9 l h h o

10 m l l w

11 m l m n

12 m l h s

13 m m l o

14 m m m w

15 m m h n

16 m h l o

17 m h m w

18 m h h w

19 h l l n

20 h l m s

21 h l h s

22 h m l w

23 h m m s

24 h m h s

25 h h l o

26 h h m w

27 h h h s

Rule	Impact	Cost	Technical-ability	Priority
1	l	l	l	o
2	l	l	m	w
3	l	l	h	n
4	l	m	l	o
5	l	m	m	o
6	l	m	h	w
7	l	h	l	o
8	l	h	m	o
9	l	h	h	o
10	m	l	l	w
11	m	l	m	n
12	m	l	h	s
13	m	m	l	o
14	m	m	m	w
15	m	m	h	n
16	m	h	l	o
17	m	h	m	w
18	m	h	h	w
19	h	l	l	n
20	h	l	m	s
21	h	l	h	s
22	h	m	l	w
23	h	m	m	s
24	h	m	h	s
25	h	h	l	o
26	h	h	m	w
27	h	h	h	s

Table 7

The priorities of the security requirements of OBS

Goal	Linguistic Priority Values
	R ₁	R ₂	R ₃	R ₄	R ₅	R ₆	R ₇	R ₈	R ₉	R ₁₀	R ₁₁	R ₁₂
S	S	W	W	S	N	W	N	N	W	N	W	O
G ₁	S	W	W	S	N	W	N	N	W	N	W	-
G ₂	S	W	W	S	N	W	N	N	-	-	-	-
G ₃	-	W	W	S	-	-	-	-	-	-	-	-
G ₄	-	W	W	S	-	-	-	-	-	-	-	-
G ₅	-	-	-	-	N	W	N	N	-	-	-	-
G ₆	-	-	-	-	N	O	W	N	-	-	-	-
G ₇	-	-	-	-	N	N	N	-	-	-	-	-
G ₈	-	-	-	-	-	-	-	N	-	-	-	-
G ₉	-	-	-	-	N	W	N	N	-	-	-	-
G ₁₀	-	-	-	-	-	-	-	-	W	N	-	-
G ₁₁	-	-	-	-	-	-	-	-	W	-	-	-
G ₁₂	-	-	-	-	-	-	-	-	-	-	W	-
G ₁₃	-	-	-	-	-	-	-	-	-	-	-	O

Considering the priorities of the requirements with respect to different security goals enables goal-based selection of security requirements in PAPS. For example, requirement “R₇: achieve password encryption” of OBS is normally required for the satisfaction of goal “G₂: avoid [unauthorized online transfer]” while it is weakly recommended as far as satisfying “G₆: avoid guess password” is concerned. Thus, R₅ and R₈ are preferred as they are prioritized normal with respect to G₆ (Table 7). Figure 5 demonstrates the membership functions of the FIS inputs (impact, cost, and technical-ability) and output (priority) for prioritizing R₇ with respect to the top-level security goal S.

Fig.5

Inferring the fuzzy priority of R₇ with respect to the top-level security goal S. The membership values of the FIS inputs/output are denoted by vertical lines.

5.3 Partial selection

Our proposed PAPS framework allows for partial selection of a security requirement x if budget is tight or x conflicts with other quality aspects of the system. For instance, implementing “x: achieve a complex password policy” may reduce the usability of the system [49]. When partial satisfaction of x is tolerated, however, a less complex password policy can be implemented to maintain the usability of the system. Partial selection in PAPS comprises two major components (Figure 2): (i) defuzzifying the linguistic priorities of the security requirements and (ii) RELAX-ing [18, 21] the satisfaction conditions of those requirements based on their corresponding defuzzified priorities.

5.3.1 Defuzzification

As discussed earlier, security requirements can be partially selected in PAPS by RELAX-ing their satisfaction conditions; the extent to which a requirement needs to be satisfied is determined by its linguistic priority. But the satisfaction conditions of the requirements are quantified by numbers (e.g., % availability, the length of a password, and the number of login attempts). As such, it is important to provide a mechanism to map the linguistic priorities into their corresponding crisp values when needed. We have achieved this by defuzzifying the priorities of the security requirements using their corresponding membership functions (FIS output in Table 5). The defuzzified priority of a requirement specifies its Required Degree of Satisfaction (RDS). Function “PrioritizationAndSelection” in Figure B.2 achieves defuzzification using the Center of Gravity (COG) method [50].

5.3.2 RELAX-ation

RELAX-ation is the final step in PAPS (Figure 2), that aims to RELAX the satisfaction conditions of the security requirements whose partial satisfaction is tolerated. This will be achieved by specifying the required degree of satisfaction (RDS) for each requirement; RDS values are determined by the defuzzified priorities of the requirements as discussed in Section 5.3.1. We use a combination of RELAX [21] and KAOS languages to formally describe the RELAX-ed securityrequirements.

The fuzzy semantic of the RELAX statements properly captures the partiality of security requirements [18]. As an example, consider RELAX-ing one of the security requirements of OBS: “R₆: achieve password policy”. Based on Table 8, SRL [S] [R6]= ‘weak’, that means R₆ can be tolerated to be weakly satisfied; R₆ can be partially included (selected) in SRL[S] through RELAX-ing its satisfaction condition. If a less complex password encryption can be tolerated in SRL [S], the satisfaction condition of R₆ can be RELAX-ed with the semantic given by (5), that is “system shall generally (G) achieve a password policy [complexity] as close as possible to (R₆ . RDS × R₆ . OV) at all times (A). OV denotes the Optimal Value for the satisfaction criterion of R₆. Also, Δ (R₆) specifies the complexity of R₆ and μ (x) is the membership function offuzzy set Z. $AG (μ (Δ (R_{6}) - R_{6} . RDS \times R_{6} . OV) \in Z)$ (5)

Table 8

Required degrees of satisfaction, denoted by RDS, for the security requirements of OBS

Goal	RDS Values
	R ₁	R ₂	R ₃	R ₄	R ₅	R ₆	R ₇	R ₈	R ₉	R ₁₀	R ₁₁	R ₁₂
S	0.82	0.25	0.25	0.82	0.59	0.36	0.42	0.55	0.35	0.55	0.25	0.13
G ₁	0.82	0.25	0.25	0.82	0.59	0.36	0.42	0.55	0.35	0.55	0.25	-
G ₂	0.82	0.25	0.25	0.82	0.59	0.36	0.42	0.55	-	-	-	-
G ₃	-	0.25	0.25	0.82	-	-	-	-	-	-	-	-
G ₄	-	0.25	0.25	0.82	-	-	-	-	-	-	-	-
G ₅	-	-	-	-	0.59	0.36	0.42	0.55	-	-	-	-
G ₆	-	-	-	-	0.55	0.24	0.35	0.55	-	-	-	-
G ₇	-	-	-	-	0.64	0.6	0.55	-	-	-	-	-
G ₈	-	-	-	-	-	-	-	0.55	-	-	-	-
G ₉	-	-	-	-	0.59	0.36	0.42	0.59	-	-	-	-
G ₁₀	-	-	-	-	-	-	-	-	0.35	0.55	-	-
G ₁₁	-	-	-	-	-	-	-	-	0.35	-	-	-
G ₁₂	-	-	-	-	-	-	-	-	-	-	0.25	-
G ₁₃	-	-	-	-	-	-	-	-	-	-	-	0.13

Phrase “complexity as close as possible to R₆ . RDS” then can be assigned to the ‘relaxed’ attribute of R₆ as explained earlier. The value of RDS maximizes the membership function μ as given by (6). Also, the fuzzy membership function μ gives the degree of satisfaction of R₆ based on the difference between the current password complexity (Δ (R₆)) and R₆ . RDS × R₆ . OV. Membership function μ has its maximum (1) at RDS as given by (6).

$\begin{matrix} μ (x) \to Z, μ (0) = 1, \\ Z = {(x_{i}, μ (x_{i})) | μ (x_{i}) \in [0, 1], x \in ℝ} \Rightarrow \\ Δ (R_{6}) = R_{6} . RDS \times R_{6} . OV \to \\ μ (Δ (R_{6}) - R_{6} . RDS \times R_{6} . OV) = 1 \end{matrix}$ (6)

Similarly, the security requirements in the SRL [S] of the running example (OBS) are RELAX-ed and listed in Table 9; the ‘relaxed’ descriptions are specified based on the satisfaction criteria of the requirements. As given in Table 9, the satisfaction criteria of the requirements are placed inside the brackets. For instance, the satisfaction criterion of R₆ is “complexity” of password policy while “length of the encryption key” is used to measure the satisfaction of R₇.

Table 9

The RELAX-ed OBS requirements. R_i . OV denotes the optimal value for the satisfaction criterion of requirement R_i

Requirement	Sample RELAX-ed Value
R₁: achieve request transaction code	[expiry rate] as close as possible to 0.82 × R₁ . OV
R₂: achieve a latency examination mechanism	[examination delay] as close as possible to 0.25 × R2_.OV
R₃: achieve a one-time pad	[randomness] as close as possible to 0.25 × R₃ . OV
R₄: achieve a SSL protocol	[entropy] as close as possible to 0.82 × R₄ . OV
R₅: achieve a password trial limitation	[trial delay] as close as possible to 0.59 × R₅ . OV
R₆: achieve a password policy	[complexity] as close as possible to 0.36 × R₆ . OV
R₇: achieve a password encryption	[length of encryption key]as many bits as 0.42 × R₇ . OV
R₈: achieve a random id	[randomness] as close as possible to 0.55 × R₈ . OV
R₉: achieve a CAPTCHA	[level of distortion] as close as possible to 0.35 × R₉ . OV
R₁₀: achieve a complex pin	[complexity] as close as possible to 0.55 × R₁₀ . OV
R₁₁: achieve an access control mechanism	[complexity] as close as possible to 0.25 × R₁₁ . OV
R₁₂: achieve a redundant server	[number of servers] as close as possible to 0.13 × R₁₂ . OV

6 Complexity analysis

In the following, we discuss the complexity of the prioritization and selection (PAS) process in PAPS.

6.1 Complexity of the prioritization process

Prioritization in PAPS comprises (a) fuzzifying the prioritization criteria and (b) inferring the priorities of the requirements (Figure 2). The fuzzification process maps the crisp values of the prioritization criteria into their corresponding fuzzy terms using fuzzy membership functions. To fuzzify all m prioritization criteria of a requirement, we need m mapping, where each mapping needs k (the number of possible values for each criterion) comparisons in the worst case. Therefore, the complexity of fuzzification for n requirements will be O (n × (m × k)).

Moreover, inference in PAPS is based on a set of fuzzy rules. For m prioritization criteria and k possible values for each criterion, k^m rules may be needed to capture all possible combinations of the values assigned to the criteria. Thus, for n requirement O (n × k^m) comparison may be needed to apply the relevant inference rules. Equation (7) gives the complexity of prioritization in PAPS for n requirements, m prioritization criteria, and k possible values for each criterion.

$\begin{matrix} O (n \times m \times k & + n \times k^{m}) \\ = O (n \times (m \times k + k^{m})) \end{matrix}$ (7)

Assuming that the number of requirements (n) is significantly greater than m and k, which is very likely in real-world software projects, (m × k + k^m) can be treated as a constant; the complexity of the prioritization process in PAPS will be O (n).

6.2 Complexity of the selection process

The selection process in PAPS comprises (a) defuzzification of the linguistic priorities of the security requirements and (b) RELAX-ing the satisfaction conditions of the requirements. Defuzzification maps the linguistic priorities of the requirements into their corresponding crisp values using the membership functions of the priorities (FIS output). Thus, for n requirements and l values for the priority of each requirement, n × l comparisons may be needed. Assuming that the optimal values for the satisfaction criteria of the requirements (OV in Table 9) are specified prior to the selection process, the RELAX-ation process is as complex as multiplying each optimal value by its corresponding required degree of satisfaction (RDS), achieved from the defuzzified priorities (Section 5.3.2). That will be n operations for n security requirements of a software system.

6.3 Overall complexity

For n requirements, m prioritization criteria, k possible values for each criterion, and l possible values for the priorities, the overall complexity of prioritization and selection in PAPS is as given by (8). $\begin{matrix} O (n \times (m \times k) + n \times (k^{m}) + n \times l + n) \\ = O (n \times (m \times k + k^{m} + l + 1)) \end{matrix}$ (8)

Assuming that the number of requirements (n) is significantly greater than m, k, and l, (m × k + k^m + l) will be a constant and therefore the overall complexity of the prioritization and selection in PAPS will be O (n). This is significantly less complex than AHP (the most reliable prioritization and selection technique [7]), which requires O (n²) operations [7]. The overall complexity of the prioritization and selection in PAPS is also less than the standard ranking-based prioritization and selection techniques such as Bubble Sort (O (n²)) and Binary Search Tree (O (n log n)) [7]. Also, it is clear that the complexity of any prioritization technique based on pairwise comparisons is at least O (n²), which is more complex than PAPS. The complexity of other prioritization and selection techniques (e.g. Cumulative Voting, EVOLVE, and Planning Game [13]), however, have not been formulated in the literature thus cannot be mathematically compared against PAPS. The linear complexity of PAPS (O (n)) is a good indicator of its scalability in practice.

7 Limitations

In this section, we discuss the limitations of our proposed PAPS framework to contain it within a full understanding of its theoretical and practical boundaries.

RELAX-ation. The PAPS framework RELAX-es the satisfaction conditions of the security requirements when tolerated (Section 5.3). That allows for a higher number of requirements to be selected, thus (a) reducing the number of unattended security threats and (b) mitigating the risk of ignoring the dependencies of the security requirements. But the effectiveness of PAPS may be restricted when only a small number of the security requirements are tolerated to be RELAX-ed.

Conflicts. It has been widely recognized that the security requirements of software projects may conflict with other quality aspects of software [51] such as the usability [52] and privacy [53]. This has not been considered in PAPS to avoid further complexity. More sophisticated variations of the framework, however, are needed to explicitly account for conflicts between security and other quality aspects of software.

Computational Complexity. We demonstrated (Section 6) that the process of prioritization and selection in PAPS is less complex than the conventional prioritization and selection techniques such as AHP and Ranking-Based algorithms (e.g., Bubble Sort and Binary Search Tree). While the lower computational complexity of PAPS (O (n)) is a good indicator of its scalability, real-world experiments are needed to further verify this in practice.

Fuzzy Inference. We have used a Mamdani-based fuzzy inference system (FIS) in PAPS to infer the priorities of the requirements. But there are some limitations (e.g., intersected contradictory decision boundaries) with those inference systems [54], that may impact the practicality of PAPS. Solutions to overcome these limitations have been proposed by Perera et al. [54], which can be explored in the future. Moreover, the effectiveness of PAPS may depend on how well the membership functions of the FIS inputs/outputs are defined. That requires a level of expertise, which may not be available in all software projects.

8 Conclusions and future work

In this paper, we proposed a fuzzy framework referred to as PAPS (Prioritization and Partial Selection), that enhances the accuracy of prioritizing and selecting security requirements by taking into account the partiality of security. To achieve this, the proposed framework allows for partial selection of security requirements by relaxing their satisfaction conditions, when tolerated. A fuzzy inference system is used to specify the requirement priorities, which eventually determine the satisfaction conditions of those requirements. Partial selection in PAPS helps reduce the number of ignored security requirements, thus (a) reducing the number of unattended security threats and (b) mitigating the risk of neglecting the dependencies of the requirements. To demonstrate the practicality of PAPS, we applied it to an online banking system, which served as our running example.

We are planning to extend the work in several directions. One is to develop more sophisticated variations of PAPS that consider the impacts of security requirements on other quality aspects of software such as usability and performance. We are also planning to apply the proposed framework to a real-world software project to verify its scalability in practice.

Footnotes

Appendices

References

Steiner

R.V.

and Lupu

, Towards more practical software-based attestation, Computer Networks 149 (2019), 43–55.

Lounis

, Stochastic-based semantics of attack-defense trees for security assessment, Electronic Notes in Theoretical Computer Science 337 (2018), 135–154.

Malek

, Bagheri

, Garcia

and Sadeghi

, Security and software engineering, in: Handbook of Software Engineering, Springer, 2019, pp. 445–489.

Mougouei

and Powers

D.M.

, Modeling and selection of interdependent software requirements using fuzzy graphs, International Journal of Fuzzy Systems (2017), 1–17.

Guan

, Yang

and Wang

, An ontology-based approach to security pattern selection, International Journal of Automation and Computing 13(2) (2016), 168–182.

Kotenko

and Doynikova

, Selection of countermeasures against network attacks based on dynamical calculation of security metrics, The Journal of Defense Modeling and Simulation 15(2) (2018), 181–204.

Achimugu

, Selamat

, Ibrahim

and Mahrin

M.N.

, A systematic literature review of software requirements prioritization research, Information and software technology 56(6) (2014), 568–585.

Hudaib

, Masadeh

, Qasem

M.H.

and Alzaqebah

, Requirements prioritization techniques comparison, Modern Applied Science 12(2) (2018), 62.

McZara

, Sarkani

, Holzer

and Eveleigh

, Software requirements prioritization and selection using linguistic tools and constraint solvers – a controlled experiment, Empirical Software Engineering 20(6) (2015), 1721–1761.

10.

Achimugu

, Selamat

and Ibrahim

, A web-based multicriteria decision making tool for software requirements prioritization, in: International Conference on Computational Collective Intelligence, Springer, 2014, pp. 444–453.

11.

Singh

D.K.

and Kaushik

, Framework for fuzzy rule based automatic intrusion response selection system (frairss) using fuzzy analytic hierarchy process and fuzzy topsis, Journal of Intelligent & Fuzzy Systems (Preprint) (2018), 1–13.

12.

Nazari-Shirkouhi

, Miri-Nargesi

and Ansarinejad

, A fuzzy decision making methodology based on fuzzy ahp and fuzzy topsis with a case study for information systems outsourcing decisions, Journal of Intelligent&Fuzzy Systems 32(6) (2017), 3921–3943.

13.

Evbota

, Knauss

and Sandberg

, Scaling up the planning game: Collaboration challenges in large-scale agile product development, in: International Conference on Agile Software Development, Springer, Cham, 2016, pp. 28–38.

14.

Assal

and Chiasson

, Security in the software development lifecycle, in: Fourteenth Symposium on Usable Privacy and Security (SOUPS 2018), 2018, pp. 281–296.

15.

Jaatun

M.G.

, Bernsmed

, Cruzes

D.S.

and Tøndel

I.A.

, øndel, Threat modeling in agile software development, in: Exploring Security in Software Architecture and Design, IGI Global, 2019, pp. 1–14.

16.

Mougouei

and Factoring requirement dependencies in software requirement selection using graphs and integer programming, in: Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering, ASE 2016, ACM, New York, NY, USA, 2016, pp. 884–887.

17.

Mougouei

, Powers

D.M.W.

and Moeini

, Dependencyaware software release planning, in: Proceedings of the 39th International Conference on Software Engineering Companion, ICSE-C ’17, IEEE Press, Piscataway, NJ, USA, 2017, pp. 198–200.

18.

Mougouei

, Moghtadaei

and Moradmand

, A goal-based modeling approach to develop security requirements of fault tolerant security-critical systems, in: Computer and Communication Engineering (ICCCE), 2012 International Conference on, IEEE, 2012, pp. 200–205.

19.

Chen

F.-H.

, Shen

and Shi

F.-G.

, A new approach to the fuzzification of arity, jhc and cup of l-convexities, Journal of Intelligent & Fuzzy Systems 34(1) (2018), 221–231.

20.

Yolcu

, Bas

and Egrioglu

, A new fuzzy inference system for time series forecasting and obtaining the probabilistic forecasts via subsampling block bootstrap, Journal of Intelligent & Fuzzy Systems (Preprint) (2018), 1–10.

21.

Whittle

, Sawyer

, Bencomo

, Cheng

B.H.

and Bruel

J.-M.

, Relax: A language to address uncertainty in self-adaptive systems requirement, Requirements Engineering 15(2) (2010), 177–196.

22.

Thakurta

, A framework for prioritization of quality requirements for inclusion in a software project, Software Quality Journal 21(4) (2013), 573–597.

23.

Greer

and Ruhe

, Software release planning: An evolutionary and iterative approach, Information and Software Technology 46(4) (2004), 243–253.

24.

Ramzan

, Jaffar

M.A.

and Shahid

A.A.

, Value based intelligent requirement prioritization (virp): Expert driven fuzzy logic based prioritization technique, International Journal Of Innovative Computing, Information And Control 7(3).

25.

Avesani

, Bazzanella

, Perini

and Susi

, Facing scalability issues in requirements prioritization with machine learning techniques, in: 13th IEEE International Conference on Requirements Engineering (RE’05), IEEE, 2005, pp. 297–305.

26.

Alali

, Almogren

, Hassan

M.M.

, Rassan

I.A.

and Bhuiyan

M.Z.A.

, Improving risk assessment model of cyber security using fuzzy logic inference system, Computers & Security 74 (2018), 323–339.

27.

Lin

, Wang

Y.-M.

and Chen

S.-Q.

, Multistage decision making based on prioritization of hesitant multiplicative preference relations, Journal of Intelligent & Fuzzy Systems 32(1) (2017), 691–701.

28.

Oztaysi

and Cevik

, Onar and C. Kahraman, Fuzzy multicriteria prioritization of urban transformation projects for istanbul, Journal of Intelligent & Fuzzy Systems 30(4) (2016), 2459–2474.

29.

Lee

M.-C.

, Information security risk analysis methods and research trends: Ahp and fuzzy comprehensive method, International Journal of Computer Science & Information Technology 6(1) (2014), 29.

30.

Borgman

, Mubarak

and Choo

K.-K.R.

, Cyber security readiness in the south australian government, Computer Standards & Interfaces 37 (2015), 1–8.

31.

Sharef

N.M.

and Martin

, Evolving fuzzy grammar for crime texts categorization, Applied Soft Computing 28 (2015), 175–187.

32.

Urrutia

A.T.

, An approach to measuring complexity within the boundaries of a natural language fuzzy grammar, in: International Symposium on Distributed Computing and Artificial Intelligence, Springer, 2018, pp. 222–230.

33.

Mougouei

and Nurhayati

, A fuzzy-based technique for deD. scribing security requirements of intrusion tolerant systems, International Journal of Software Engineering and its Applications 7(2) (2013), 99–112.

34.

Sindre

and Opdahl

A.L.

, Eliciting security requirements with misuse cases, Requirements Engineering 10(1) (2005), 34–44.

35.

Whittle

, Sawyer

, Bencomo

, Cheng

B.H.

and Bruel

J.-M.

, Relax: Incorporating uncertainty into the specification of selfadaptive systems, in: 2009 17th IEEE International Requirements Engineering Conference, IEEE, 2009, pp. 79–88.

36.

Van

, Lamsweerde, Elaborating security requirements by construction of intentional anti-models, in: Proceedings of the 26th International Conference on Software Engineering, IEEE Computer Society, 2004, pp. 148–157.

37.

Abdo

, Kaouk

, Flaus

J.-M.

and Masse

, A safety/security risk analysis approach of industrial control systems: A cyber bowtie–combining new version of attack tree with bowtie analysis, Computers & Security 72 (2018), 175–195.

38.

Erdogan

, Nguyen

P.H.

, Seehusen

, Stølen

, Hofstad

and Aagedal

J. Ø.

, An evaluation of a test-driven security risk analysis approach based on two industrial case studies, in: Exploring Security in Software Architecture and Design, IGI Global, 2019, pp. 69–103.

39.

Bachy

, Nicomette

, Kaâniche

and Alata

, Smart-tv security: Risk analysis and experiments on smart-tv communication channels, Journal of Computer Virology and Hacking Techniques (2018), 1–16.

40.

Karlsson

and Ryan

, A cost-value approach for prioritizing requirements, IEEE Software 14(5) (1997), 67–74.

41.

Thaker

and Nagori

, Analysis of fuzzification process in fuzzy expert system, Procedia Computer Science 132 (2018), 1308–1316.

42.

Sun

, Li

, Gao

and Xia

, A mamdani fuzzy inference approach for assessing ecological security in the pearl river delta urban agglomeration, china, Ecological Indicators 94 (2018), 386–396.

43.

Zadeh

L.A.

, Fuzzy sets, Information and control 8(3) (1965), 338–353.

44.

Wang

, Huang

, Yuan

and Li

, A multi-granularity fuzzy computing model for sentiment classification of chinese reviews, Journal of Intelligent & Fuzzy Systems 30(3) (2016), 1445–1460.

45.

Lewis

R.W.

, Programming industrial control systems using IEC 1131-3, no. 50, Iet, 1998.

46.

Elragal

H.M.

, Mamdani and takagi-sugeno fuzzy classifier accuracy improvement using enhanced particle swarm optimization, Journal of Intelligent & Fuzzy Systems 26(5) (2014), 2445–2457.

47.

Mamdani

E.H.

, Application of fuzzy algorithms for control of simple dynamic plant, Electrical Engineers, Proceedings of the Institution of 121(12) (1974), 1585–1588.

48.

Avatefipour

and Nafisian

, A novel electric load consumption prediction and feature selection model based on modified clonal selection algorithm, Journal of Intelligent & Fuzzy Systems 34(4) (2018), 2261–2272.

49.

Adams

and Sasse

M.A.

, Users are not the enemy, Communications of the ACM 42(12) (1999), 40–46.

50.

Van Broekhoven

, and De Baets

, Fast and accurate center of gravity defuzzification of fuzzy system outputs defined on trapezoidal fuzzy partitions, Fuzzy Sets and Systems 157(7) (2006), 904–918.

51.

Boehm

and Franch

, Conflicts and synergies among quality requirements, in: 2017 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C), 2017, pp. 507–508.

52.

Dhillon

, Oliveira

, Susarapu

and Caldeira

, Deciding between information security and usability: Developing value based objectives, Computers in Human Behavior 61 (2016), 656–666.

53.

Alkubaisy

, A framework managing conflicts between security and privacy requirements, in: 2017 11th International Conference on Research Challenges in Information Science (RCIS), 2017, pp. 427–432.

54.

Perera

L.P.

, Carvalho

J.P.

and Soares

C.G.

, Solutions to the failures and limitations of mamdani fuzzy inference in ship navigation, IEEE Transactions on Vehicular Technology 63(4) (2014), 1539–1554.

55.

Berander

and Andrews

, Requirements prioritization, in: Engineering and managing software requirements, Springer, 2005, pp. 69–94.

56.

Lima

D.C.

, Freitas

, Campos

and Souza

, A fuzzy approach to requirements prioritization, in: International Symposium on Search Based Software Engineering, Springer, 2011, pp. 64–69.

57.

Duan

, Laurent

, Cleland-Huang

and Kwiatkowski

, Towards automated requirements prioritization and triage, Requirements engineering 14(2) (2009), 73–89.

A fuzzy framework for prioritization and partial selection of security requirements in software projects

Abstract

Keywords

1 Introduction

2 Related work

3 The running example

4.1.1 Modeling security requirements

Table 3 Cost and Technical-ability of OBS requirements Requirement R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 R 9 R 10 R 11 R 12 Cost 0.5 0.7 0.7 0.3 0.05 0.5 0.2 0.01 0.6 0.1 0.7 1.0 Technical-ability 1.0 0.2 0.1 0.9 1.0 0.3 0.2 1.0 0.1 1.0 0.2 0.2

5.1 Data preprocessing

5.1.1 Constructing a security requirement list

5.1.2 Calculating the impacts

5.2.1 Fuzzification

5.3.1 Defuzzification

5.3.2 RELAX-ation

6.1 Complexity of the prioritization process

6.3 Overall complexity

8 Conclusions and future work

Footnotes

Appendices

References

Table 3
Cost and Technical-ability of OBS requirements

Requirement R ₁ R ₂ R ₃ R ₄ R ₅ R ₆ R ₇ R ₈ R ₉ R ₁₀ R ₁₁ R ₁₂

Cost 0.5 0.7 0.7 0.3 0.05 0.5 0.2 0.01 0.6 0.1 0.7 1.0

Technical-ability 1.0 0.2 0.1 0.9 1.0 0.3 0.2 1.0 0.1 1.0 0.2 0.2