Aspect-oriented specification of threat-driven security requirements

Specification and traceability of security requirements is still a challenge since modeling and analysis of security aspects of systems require additional efforts at the very beginning of software development. The topological functioning model is a formal mathematical model that can be used as a reference model for functional and non-functional requirements of the system. It can also serve as a reference model for security requirements. The purpose of this study is to determine the approach to how security requirements can be specified and traced using the topological functioning model. This article demonstrates the suggested approach and explains its potential benefits and limitations.

Modeling Security and Privacy Requirements: a Use Case-Driven Approach

Teleoperated driving technology enables human operators to control vehicles remotely, thereby reducing the need for the driver’s physical presence within the vehicle. Although this innovation enhances operational flexibility, it introduces security challenges that, if unaddressed, could undermine the reliability and safety of Teleoperated Driving Systems (TDS). This paper presents a comprehensive security risk analysis and architectural framework for TDS, emphasizing the system architecture. Our study combines an in-depth review of the existing literature with a structured risk management assessment to analyze TDS assets and data flows. By detailing the system and business assets, their interconnections, and the unique vulnerabilities inherent to TDS, we define critical security threats – ranging from unauthorized control and data manipulation to vulnerabilities in session management protocols and network configurations. The selected security risk management approach guides our risk analysis, maps security threats and vulnerabilities to the corresponding security requirements and controls, and provides a prioritized strategy for risk treatment. Validation results show that our risk analysis achieves strong coverage, with a third-party threat analysis tool confirming eighteen (18) of the thirty-two (32) identified security threats and highlighting three (3) additional scenarios, while missing fourteen (14) threats mainly due to tool limitations. Our results offer practitioners a practical blueprint for identifying and managing security risks in TDS.

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.

Software security testing is an important technique for discovering software vulnerabilities that violate security requirements. Existing security testing methods, however, seldom generate security tests directly from security requirements specifications. To address this issue, this paper presents an approach for constructing security test models from the artifacts of misuse case modeling (i.e., use/misuse cases and mitigation use cases), which is a popular method for security requirements specification in the software development process. The security test models can then be used to automatically generate security tests, which consist of test inputs (normal behaviors from use cases and attack actions from misuse cases) and test oracles from mitigation use cases. We have applied the approach to two case studies. One case study demonstrates that the proposed approach can build security test models in a structured fashion such that the generated security tests are as effective as reported in the literature. The second case study applies the proposed approach to an ongoing software development project. The security tests have revealed at least 24 vulnerabilities, and are very helpful for the development team to improve the security of the software implementation. This demonstrates that the proposed approach is effective in the software development process.

Today's ongoing trend towards intense usage of web service based applications in daily business and everybody's daily life poses new challenges for security testing. Additionally, such applications mostly not execute in their own runtime environment but instead are deployed in some data center, run alongside multiple other applications, and serve different purposes for sundry user domains with diverging security requirements. As a consequence, security testing also has to adapt to be able to meet the necessary requirements for each application in its domain and its specific security requirements. In addition, security testing needs to be feasible for both service providers and consumers. In our paper we identify drawbacks of existing security testing approaches and provide directions for meeting emerging challenges in future security testing approaches. We also introduce and describe the idea of language-oriented security testing, a novel testing approach building upon domain-specific languages and domain knowledge to meet future requirements in security testing.

Given the ever-growing body of knowledge, healthcare improvement hinges more than ever on efficient knowledge transfer to clinicians and patients. Promoted initially by the Institute of Medicine, the Learning Health System (LHS) framework emerged in the early 2000s. It places focus on learning cycles where care delivery is tightly coupled with research activities, which in turn is closely tied to knowledge transfer, ultimately injecting solid improvements into medical practice. Sensitive health data access across multiple organisations is therefore paramount to support LHSs. While the LHS vision is well established, security requirements to support them are not. Health data exchange approaches have been implemented (e.g., HL7 FHIR) or proposed (e.g., blockchain-based methods), but none cover the entire LHS requirement spectrum. To address this, the Sensitive Data Access Model (SDAM) is proposed. Using a representation of agents and processes of data access systems, specific security requirements are presented and the SDAM layer architecture is described, with an emphasis on its mix-network dynamic topology approach. A clinical application benefiting from the model is subsequently presented and an analysis evaluates the security properties and vulnerability mitigation strategies offered by a protocol suite following SDAM and in parallel, by FHIR.

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.

Recently, business transformation towards the used of Information and Communication Technology (ICT) is a necessity toward rapid industries and the paradigm shifted to sustain business competitiveness. The holistic electronic approach is one of business innovations, especially in handling a lot of tender documentations and process in an electronic environment namely as e-Tendering. Unfortunately, the existing tender process transformation in the electronic approach is not properly followed certain standard and guideline, especially in establishing a good e-Tendering functional requirements specification to ensure the organizations would be in the best served. This is important to ensure a good e-Tendering system can be developed by e-Tendering developers based on a good e-Tendering functional requirement specifications. The requirements specification is a process of documenting user and system requirements. Commonly, user and system requirements should be clear, unambiguous, easy to understand, complete, and consistent. In practice, this is difficult to achieve due to interpretation of the requirements in different ways by stakeholders, which are often inherent conflicts and inconsistencies of the requirements. The implementation of the existing e-tendering still remains uncertainties, especially in defining the functional requirements of the e-tendering system. Therefore, this study aims to construct the e-Tendering functional requirement model using requirement template in natural language representation approach. Moreover the development of this system requirement model may provide a consistency to the requirements representation. The study uses UN/CEFACT Business Standard of the e-Tendering Business. The identified functional requirements are designed by using Requirement Template to ensure the reliability and understandability of requirements. Besides, the proposed functional requirements is constructed by adapting the natural language and verified by expert review approaches. As a result, this study proposed a functional requirements specification of the e-Tendering that contains detailed description which can be referred by software practitioners in developing a secure e-tendering system effectively.

Formal methods offer a precise and concise way of expressing system requirements which can be tested and validated with formal proofs techniques. However, their application in the development of security aware industrial systems have been associated with high costs due to the difficulty in integrating the functional and security requirements which are generated in an ad hoc manner. Reducing this cost has been a subject of interest in software requirements engineering research. In this paper we propose a formal technique for concurrent generation of functional and security requirements that can help provide a systematic way of accounting for security requirements while specifying the functional requirements of a software. With this technique, the functional behaviors of the system are precisely defined using the Structured Object-Oriented Formal Language (SOFL). The security rules are systematically explored with the results incorporated into the functional specification as constraints. The resultant specification then defines the system functionality that implies the conformance to the security rules. Such a specification can be used as a firm foundation for implementation and testing of the implementation. We discuss the principle of integrating security rules with functional specifications and present a case study to demonstrate the feasibility of our technique.

The aim of this article is to describe a method that helps analysts to translate qualitative data gathered in the field, collected for the purpose of requirements specification, to a model usable for software engineers. Requirements specification constitutes three different parts: functional requirements, quality requirements, and nonfunctional requirements. The first one specifies how the software system should function, who are the actors, and what are the input and output of the functions. The second one specifies what quality requirements the software should meet while operating in context of its environment such as reliability, usability, efficiency, portability, and maintainability. Finally, the third part specifies other requirements including context of use and development constraints. Examples of context of use are where and when the system is used, and examples of development constraints are human resources, cost and time constraints, technological platforms, and development methods. The role of the requirements specification is to give software engineers a basis for software design, and, later in the software development life cycle, to validate the software system. Requirements specification can also serve the purpose of validating users’ or customers’ view of the requirements of the system. On one hand, there has been a growing trend towards analyzing needs of the user and abilities through participatory design (Kuhn & Muller, 1993), activity theory (Bertelsen & Bødker, 2003), contextual design (Beyer & Holtzblatt, 1998), user-centered design (Gulliksen, Göransson, & Lif, 2001), and co-design and observation as in ethnography (Hughes, O’Brien, Rodden, Rouncefield, & Sommerville, 1995). Common to these methods is that qualitative data (Taylor & Bogdan, 1998) is collected, to understand the future environment of the new system, by analyzing the work or the tasks, their frequency and criticality, the cognitive abilities of the user and the users’ collaborators. The scope of the information collected varies depending on the problem, and sometimes it is necessary to gather data about the regulatory, social, and organizational contexts of the problem (Jackson, 1995) to be solved. The temporal and spatial contexts describe when the work should be carried out and where. On the other hand, software engineers have specified requirements in several different modelling languages that range from semiformal to formal. Examples of semiformal languages are UML (Larman, 2002), SADT, and IDEF (Ross, 1985). Examples of the latter are Z (Potter, Sinclair, & Till, 1996), VDM or ASM. Those are modelling languages for software development, but some languages or methods focus on task or work modelling such as Concurrent Task Trees (Paterno, 2003) and Cognitive Work Analysis (Vicente, 1999). Others emphasize more the specification method than a modelling language. Examples of the former are Scenario-Based Design (SBD) (Rosson & Carroll, 2002) and Contextual Design (Beyer & Holtzblatt, 1998). In practice, many software developers use informal methods to express requirements in text, e.g., as narrations or stories. Agile Development Methods (Abrahamsson, Warsta, Siponen, & Ronkainen, 2003) emphasize this approach and thereby are consistent with their aim of de-emphasizing methods, processes, and languages in favor of getting things to work. A popular approach to requirements elicitation is developing prototypes. There has been less emphasis on bridging the gap between the above two efforts, for example, to deliver a method that gives practical guidelines on how to produce specifications from qualitative data (Hertzum, 2003). One reason for this gap can be that people from different disciplines work on the two aspects, for example, domain analysts or experts in HCI, and software engineers who read and use requirements specification as a basis for design. Another reason for this gap may be in the difference in the methods that the two sides have employed, that is, soft methods (i.e., informal) for elicitation and analysis and hard methods (i.e., formal) for specification. In this article, we suggest a method to translate qualitative data to requirements specification that we have applied in the development of a Smart Space for Learning. The process borrows ideas from or uses scenarios, interviews, feature-based development, soft systems methodology, claims analysis, phenomenology, and UML.

Recent years have seen much growing attention on RFID security. However, little work has been performed to address the security issues in the context of supply chain management, which is exactly the major field for RFID applications. Existing RFID solutions cannot be applied directly in this field because of a set of special RFID security requirements to be addressed for supply chain management. The major contribution of this paper is to identify the unique set of security requirements in supply chains and to propose a practical design of RFID communication protocols that satisfy the security requirements.

Cloud storage is becoming an option for users in keeping their data online, but it comes with the security threats and challenges of protecting their data from threats. Many security frameworks have been suggested by existing studies, governing bodies, industry standards etc. as guidelines to be implemented by cloud service providers (CSPs) but the complete set of controls cannot be fully implemented due to several challenges such as decreasing availability, less user convenience, need of a robust infrastructure etc. Therefore, there is a need to investigate the security requirements and threats which will enable efficient security protection to protect data in cloud storage. This paper will discuss security requirements and analyses existing cloud security threats. The threats will be modelled in a cloud storage scenario. Future work will involve confirming the security framework using a triangulation method. This will involve confirming the idea with experts and simulations of the designated security requirements on cloud storage that will be used to test the framework.

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.

Boundary artefacts are shared artefacts that support collaboration by allowing different groups to interpret the same information in different ways. Software development activities benefit from them, as a single artefact can support stakeholders across different organisational boundaries. When these artefacts contain inconsistencies, such as incorrect information, practitioners’ trust in them may decrease, leading to inefficiencies in task execution. This study developed and evaluated a guideline to support the creation of boundary artefacts in software engineering contexts. We conducted a longitudinal, multi-phase study embedded in an industrial setting. The guideline was developed based on a literature review and prior findings from a previous case study and was then submitted for practitioner evaluation. A post-implementation analysis of the guideline was carried out after a period without researcher intervention. Our guideline consists of 10 principles grouped into three categories: (1) Scope: stakeholders, boundaries, and terminology; (2) Structure: artefact format, transference, granularity, and additions; and (3) Management: evaluation, ownership, governance, and integration. Practitioner evaluations suggested that these principles support the creation of reliable, predictable, and functional boundary artefacts. However, practitioners also noted challenges during use, including the time-consuming nature of the activity and difficulties in understanding the concept of boundary artefact. Overall, the guideline was well received. After the non-intervention period, it was adopted as a standard by the partner company for artefacts such as security testing, standards documentation, and requirements specifications. Adoption challenges persisted, including cultural barriers and comprehension issues. Further applications across different artefacts could clarify how the principles influence their reliability, functionality, and predictability.