Decision-Making in Security Requirements Engineering with Constrained Goal Models

Given the wide distribution of software and its current growth, security is inevitable, and software systems have become more complex. To avoid the complexity and protect valuable assets of software systems, researchers, and practitioners in the fields of security requirement engineering (SRE) and security assurance advise incorporating security requirements early in software development life cycle (SDLC). Nowadays, security requirements specification and identification are an active research area for ensuring the effectiveness of software systems. However, security requirement identification is a challenging task due to sheer numbers of threats and attacks to a software system. Previous researchers have identified different SRE techniques, each looking at the same problem from a different perspective. Therefore, a literature review conducted on SRE techniques. We compared and analyzed different SRE techniques to find the most suitable SRE techniques for researchers and practitioners. Selected SRE techniques compared based on various parameters, such as different attributes, requirement elicitation, requirement analysis, project size, and integration of standards. The literature also indicates that among SRE approaches, security quality requirements engineering (SQAURE), secure tropos, security requirements engineering process (SREP), and comprehensive lightweight application security process (CLASP) are the most used SRE approaches that focus on activities such as threats, security requirements identification, and security objectives identification. Unfortunately, several SRE approaches fail to explicitly integrate the security standard and security assurance perspective. Three questions developed for this study: Question 1 is based on comparison of existing SRE approaches, Question 2 is based on SRE with security requirements elicitation and analysis, and Question 3 highlights the incorporation of security requirements assurance by SRE approaches implicitly or explicitly. The researcher must work with the developer to easily adopt SRE approaches to elicit and ensure security requirements for the software system.

Security is now the most critical feature of any computing systems. Eliciting and analyzing security requirements in the early stages of the system development process is highly recommended to reduce security vulnerabilities which might be found in the later stages of the system development process. In order to address this issue, we will propose a new extension of the misuse case diagram for analyzing and eliciting security requirements with special focus on assets and security goals. We will also present the process model in which business requirements and system requirements related to security features are separately analyzed and elicited in different phases. This process model helps us to analyze the requirements related to business goals in an earlier phase and to the system goals in a later phase so that any concerns related to them are dealt with separately. We will illustrate our approach with a case study taken from an accounting software package.

With the development of software technology, software security is receiving more and more attention. Security requirement is a key stage in the process of software development. In the present research, we propose a method to elicit security requirements; that is developed based on safety knowledge base. In the method, we perform analysis based on the asset, threat and Common Criteria security function components. Then, we summarize the relationship of the three. Based on this, we establish a safety knowledge base. Starting from the functional requirements of the application system, the system assets will be analyzed and matched automatically based on the established safety knowledge base, and finally we elicit the security requirements. The approach is very effective for the purpose of security requirement analysis, and elicits security requirements easily and efficiently. It will be very helpful for security software development.KeywordsSecurity RequirementsAssetThreatSecurity Functional ComponentCommon Criteria

To enjoy the full benefits of cloud computing, it is necessary to have built-in security, privacy, compliance and legal requirements for the cloud implementation and use. Each industry has its own risk levels that it could work within. A company, which is planning to use public cloud services, should be conscious of the regulations and industry risks and need to monitor it and abide by the same. This is due to multi-tenant and open to all nature of public cloud. A thorough risk analysis must be done initially with a public cloud provider. The main objective is to identify the existing vulnerabilities and to implement the measures to counter those threats. There are a variety of risks such as vendor lock-in, non-compliance, poor provisioning, unauthorized access, loss of control, Service Level Agreement (SLA) violations, Internet attacks, etc. To alleviate the risks, there are several measures that could be deployed. This paper deals with mitigation mechanism, security requirements and various risks associated with public cloud.

In this paper, we discuss the security issue in wireless home network (WHN) and give solution. First, we summarize the security threats and requirements of WHN, and analyze the characteristics of WHN and their influences to the design of security mechanisms. Then, based on the security threats and requirements that we have analyzed, we introduce some security mechanisms to protect the WHN. Furthermore, some alternative mechanisms are proposed for the variety of devices to choose according to their security requirements and capabilities, for example, the security delegation service (SDS) provides an efficient solution for wireless devices with low computation capability and resources to use the widely applied security protocols such as LPSEC and TLS. Finally, the security analysis is presented to demonstrate that the proposed security mechanisms are robust and efficient to secure the WHN.

Security requirements analysis is gaining growing attention as new vulnerabilities and threats are emerging on daily basis, the systematic evaluation of security requirements is of utmost importance among the various decisions to be made related to security. This short contribution proposes using a 3-dimensional vector for quantitative evaluation of security requirements, which takes into account the importance of assets to be protected, the vulnerability of the system and the trustworthiness of environment.

Software applications are essential for managing daily life activities, including social interactions and business transactions, that significantly increase the need for security in sharing sensitive information. Misuse case modeling is used for identifying and analyzing security requirements in software applications. However, security threats and their corresponding mitigations are inherently cross-cutting concerns. These concerns are scattered and tangled within multiple functional requirements and cannot be modularized using traditional object-oriented techniques. The realization of misuse cases causes crosscutting threats and corresponding mitigations to be scattered and tangled across use cases, resulting in ambiguity, incomplete understanding, and insufficient analysis of security requirements. This study proposes a misuse case modelling method called Aspect-oriented Formalized Misuse Case (AFMUC). It specifies crosscutting security threats separately as an aspect misuse case and integrates them with use cases using an aspect-oriented approach. AFMUC provides structured guidelines and restriction rules for modeling crosscutting security threats and corresponding mitigations using aspect-oriented constructs such as Pointcut, Joinpoint Advice, and Introduction. The aspect threat model is then woven into the base use case model. Similarly, an aspect mitigation model is proposed to specify crosscutting mitigations following the AFMUC restriction rules. The aspect mitigation model is then woven into the base misuse case model. The proposed approach is applied to a case study and evaluated through a controlled experiment involving twenty-four students with a background in information security. The findings indicate that the AFMUC approach is practical and unambiguous for specifying and analyzing crosscutting security requirements. However, some aspect-oriented modeling constructs and restriction rules have been misapplied by students. This shows that while students favored the AFMUC approach, they may have found it challenging to apply the aspect-oriented constructs and restriction rules due to a limited exposure to aspect-oriented modelling.

Today's software systems are too complex to ensure security after the fact – security has to be built into systems by design. To this end, model-based techniques such as UMLsec support the design-time specification and analysis of security requirements by providing custom model annotations and checks. Yet, a particularly challenging type of complexity arises from the variability of software product lines. Analyzing the security of all products separately is generally infeasible. In this work, we propose SecPL, a methodology for ensuring security in a software product line. SecPL allows developers to annotate the system design model with product-line variability and security requirements. To keep the exponentially large configuration space tractable during security checks, SecPL provides a family-based security analysis. In our experiments, this analysis outperforms the naive strategy of checking all products individually. Finally, we present the results of a user study that indicates the usability of our overall methodology.

Context and motivation: Cyber-Physical Systems (CPSs) are gaining priority over other systems. The heterogeneity of these systems increases the importance of security. Both the developer and the requirement analyst must consider details of not only the software, but also the hardware perspective, including sensor and network security. Several models for secure software engineering processes have been proposed, but they are limited to software; therefore, to support the processes of security requirements, we need a security requirements framework for CPSs. Question/Problem: Do existing security requirements frameworks fulfil the needs of CPS security requirements? The answer is no; existing security requirements frameworks fail to accommodate security concerns outside of software boundaries. Little or even no attention has been given to sensor, hardware, network, and third party elements during security requirements engineering in different existing frameworks. Principal Ideas/results: We have proposed, applied, and assessed an incremental security requirements evolution approach, which configures the heterogeneous nature of components and their threats in order to generate a secure system. Contribution: The most significant contribution of this paper is to propose a security requirements engineering framework for CPSs that overcomes the issue of security requirements elicitation for heterogeneous CPS components. The proposed framework supports the elicitation of security requirements while considering sensor, receiver protocol, network channel issues, along with software aspects. Furthermore, the proposed CPS framework has been evaluated through a case study, and the results are shown in this paper. The results would provide great support in this research direction.

Security requirements play a vital role in the software development process to gain secured software. The security levels of each software system can be varied depending on multiple factors, such as information processing or storing in the software system, business criticality of the software system, or features and functions of the system. However, the understanding of these factors has not been done early and has little or no involvement from the business users (end-users or system owners), who have the best understanding of how the system should be used in their business and the business impacts. As a result, the system design is done without awareness of these factors. Most of the time designing the system to address security concerns is done late in the development lifecycle, which causes extra money, effort, and time from the development team. In this paper, we propose a framework to help elicit the security requirements from business users based on the survey questions. The framework recommends a set of security requirements and implementation methods that are suitable for the business operations of the system. Two web applications with 12 business users for each application were selected to experiment with the effectiveness of the framework. The framework's suggested results were tested for conformity against a set of security recommendations from four security experts. We found that the security requirements and recommendations from the framework have an average 89% conformity for the WFMS system and a 93% conformity for the ASMS system with the expert recommendations.

As we analyze the latest occurring Advanced Persistent Threats (APT), we understand that attackers tend to conduct their methods by various means and ways, and are not limited to just a single pattern. Even though threats are represented by using a variety of modeling techniques, very little research has been done to learn about the security requirements needed from the understanding of commonly rooted causes of these threats. We propose a layered conceptual framework to better understand the problem from specific instances to generalized abstractions, so that it can eventually provide a good set of security requirements. In this framework, we propose building the ontology based on the Goal-based Model and Activity Diagram, and showing how to understand the context of the problem domain with extended relationships between concepts. We expect that our work can provide a foundation of good insight of the problem domain of security requirements and that we elicit security requirements through this work based on a preliminary case study on Stuxnet.

Caring for security at requirements engineering time is a message that has finally received some attention recently. However, it is not yet very clear how to achieve this systematically through the various stages of the requirements engineering process. The paper presents a constructive approach to the modeling, specification and analysis of application-specific security requirements. The method is based on a goal-oriented framework for generating and resolving obstacles to goal satisfaction. The extended framework addresses malicious obstacles (called anti-goals) set up by attackers to threaten security goals. Threat trees are built systematically through anti-goal refinement until leaf nodes are derived that are either software vulnerabilities observable by the attacker or anti-requirements implementable by this attacker. New security requirements are then obtained as countermeasures by application of threat resolution operators to the specification of the anti-requirements and vulnerabilities revealed by the analysis. The paper also introduces formal epistemic specification constructs and patterns that may be used to support a formal derivation and analysis process. The method is illustrated on a Web-based banking system for which subtle attacks have been reported recently.

Auditing security of information flows is still considered as one of the challenges in business information systems development. There are different standards and approaches that address information security. However, due to the number of information assets that have to be audited and the frequency of their changes the audit becomes complex and sometimes too subjective. Therefore, to have an opportunity to audit information security at the business process level, we needed to find a method that gives the base structure for the audit activities and supports the choice of information assets for the audit. In this regard, the Security Requirement Elicitation from Business Process approach, which focuses on information security requirements in business processes, provided an idea to ground the audit approach in business processes and information flows in them in order to facilitate integrated consideration of both, business and technology, aspects during the audit.

There are many methodologies that have been proposed in the literature for identifying the security and privacy requirements that must be satisfied by an information system in order to protect its users. At the same time, there are several “privacy principles” that have been considered as equally important for the avoidance of privacy violation incidents. However, to the best of our knowledge, there is no methodology that can cover both the identification of the security and privacy requirements and at the same time to take into account the main privacy principles. The consequence is that the designers of an information system usually follow an ad hoc approach for the identification of security/privacy requirements, thus failing to protect users in an effective way. This paper introduces the main idea behind a methodology that integrates the basic steps of well-established risk analysis methodologies with those of methodologies used for the identification of privacy requirements, considering, at the same time, the most well-known privacy principles. The proposed methodology aims to assist information system designers to come up with a complete and accurate list of all security and privacy requirements that must be satisfied by the system.

Security requirements analysis depends on how well-trained analysts perceive security risk, understand the impact of various vulnerabilities, and mitigate threats. When systems are composed of multiple machines, configurations, and software components that interact with each other, risk perception must account for the composition of security requirements. In this paper, we report on how changes to security requirements affect analysts risk perceptions and their decisions about how to modify the requirements to reach adequate security levels. We conducted two user surveys of 174 participants wherein participants assess security levels across 64 factorial vignettes. We analyzed the survey results using multi-level modeling to test for the effect of security requirements composition on participants' overall security adequacy ratings and on their ratings of individual requirements. We accompanied this analysis with grounded analysis of elicited requirements aimed at lowering the security risk. Our results suggest that requirements composition affects experts' adequacy ratings on security requirements. In addition, we identified three categories of requirements modifications, called refinements, replacements and reinforcements, and we measured how these categories compare with overall perceived security risk. Finally, we discuss the future impact of our work in security requirements assessment practice.