Identifying Potential Security Flaws using Loophole Analysis and the SECREt

In contemporary software development thereare a number of methods that attempt to ensure the securityof a system. Many of these methods are however introducedin the latter stages of development or try to address theissues of securing a software system by envisioning possiblethreats to that system, knowledge that is usually bothsubjective and esoteric.In this paper we introduce the concept of path fixationand discuss how contradictory paths or loopholes, discoveredduring requirements engineering and using only arequirements specification document, can lead to potentialsecurity flaws in a proposed system.The SECREt is a proof-of-concept prototype tool developedto demonstrate the effectiveness of loophole analysis.We discuss how the tool performs a loophole analysisand present the results of tests conducted on an actualspecification document. We conclude that loophole analysisis an effective, objective method for the discovery ofpotential vulnerabilitites that exist in proposed systems andthat the SECREt can be successfully incorporated into therequirements engineering process

A social and technical sustainability requirements catalogue

Isabel Sofia Brito is a Coordinator Professor at Polytechnic Institute of Beja, Portugal, and a member of the Centre of Technology and Systems (CTS-UNINOVA). Her main research interests are Requirements Engineering and Sustainability Requirements, Model and Data-Driven Development, Multi-Criteria Decision Making and, Big Data. She has published several papers on these topics. She has been involved in several national and international research projects (e.g., COMPETISOF, Petri-Rig, U-Bike Project). Currently, she is involved in the international applied research project HIBA—Hub Iberia Agrotech, an initiative funded by Digital Innovation Hub (DIH) and “Portugal INCoDe.2030”. She is or was involved as organiser, conference chair and program committee member in several international conferences (e.g., IEEE RE, ACM SAC, CISTI, QUATIC, CIbSE, ICT4S) and in several smaller and regional ones. Publisher Copyright: © 2022 The Author(s)Climate change calls for action from all sectors of our global economy, including ICT. Therefore, it is important to change the way we develop software to address the challenges posed by sustainability. Our goal is to contribute with a reusable sustainability requirements catalogue that helps developers be aware of sustainability-related properties worth considering during software development. The information for this catalogue was gathered via a systematic mapping study, whose results were synthesised in feature models and then modelled using iStar for a more expressive and configurable representation. A qualitative evaluation of the catalogue's readability, interest, utility, and usefulness by 50 participants from the domain, showed that around 79% of the respondents found the catalogue “Good” or “Very Good”. However, more than 5% of the expert participants found weaknesses regarding most of the evaluated questions and around 25% are neutral in their overall evaluation. This led us to evolve the initial version of the catalogue for the social and technical dimensions of sustainability to improve its completeness and usefulness. This is achieved by aligning the information gathered in the systematic mapping study with the well-established quality model of the ISO/IEC 25010:2011, as we expect most of the experts are familiar with those qualities and respective hierarchies. During this process, we found information that led us to propose two additional qualities that were not covered by the ISO standard: fairness and legislation. We applied this evolved version of the catalogue to the U-Bike project comparing the requirements elicited without the catalogue with those identified using the catalogue. The result suggests that new sustainability requirements were worth considering from a sustainability point of view, supporting the usefulness of the catalogue.publishersversionpublishe

A Reasoning Framework for Dependability in Software Architectures

The degree to which a software system possesses specified levels of software quality attributes, such as performance and modifiability, often have more influence on the success and failure of those systems than the functional requirements. One method of improving the level of a software quality that a product possesses is to reason about the structure of the software architecture in terms of how well the structure supports the quality. This is accomplished by reasoning through software quality attribute scenarios while designing the software architecture of the system. As society relies more heavily on software systems, the dependability of those systems becomes critical. In this study, a framework for reasoning about the dependability of a software system is presented. Dependability is a multi-faceted software quality attribute that encompasses reliability, availability, confidentiality, integrity, maintainability and safety. This makes dependability more complex to reason about than other quality attributes. The goal of this reasoning framework is to help software architects build dependable software systems by using quantitative and qualitative techniques to reason about dependability in software architectures

Arguing Security: A Framework for Analyzing Security Requirements

When considering the security of a system, the analyst must simultaneously work with two types of properties: those that can be shown to be true, and those that must be argued as being true. The first consists of properties that can be demonstrated conclusively, such as the type of encryption in use or the existence of an authentication scheme. The second consists of things that cannot be so demonstrated but must be considered true for a system to be secure, such as the trustworthiness of a public key infrastructure or the willingness of people to keep their passwords secure. The choices represented by the second case are called trust assumptions, and the analyst should supply arguments explaining why the trust assumptions are valid. This thesis presents three novel contributions: a framework for security requirements elicitation and analysis, based upon the construction of a context for the system; an explicit place and role for trust assumptions in security requirements; and structured satisfaction arguments to validate that a system can satisfy the security requirements. The system context is described using a problem-centered notation, then is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument is in two parts: a formal argument that the system can meet its security requirements, and structured informal arguments supporting the assumptions exposed during argument construction. If one cannot construct a convincing argument, designers are asked to provide design information to resolve the problems and another pass is made through the framework to verify that the proposed solution satisfies the requirements. Alternatively, stakeholders are asked to modify the goals for the system so that the problems can be resolved or avoided. The contributions are evaluated by using the framework to do a security requirements analysis within an air traffic control technology evaluation project

DREQUS: an approach for the Discovery of REQuirements Using Scenarios

ABSTRACT: Requirements engineering is recognized as a complex cognitive problem-solving process that takes place in an unstructured and poorly-understood problem context. Requirements elicitation is the activity generally regarded as the most crucial step in the requirements engineering process. The term “elicitation” is preferred to “capture”, to avoid the suggestion that requirements are out there to be collected. Information gathered during requirements elicitation often has to be interpreted, analyzed, modeled, and validated before the requirements engineer can feel confident that a complete set of requirements of a system have been obtained. Requirements elicitation comprises the set of activities that enable discovering, understanding, and documenting the goals and motives for building a proposed software system. It also involves identifying the requirements that the resulting system must satisfy in to achieve these goals. The requirements to be elicited may range from modifications to well-understood problems and systems (i.e. software upgrades), to hazy understandings of new problems being automated, to relatively unconstrained requirements that are open to innovation (e.g. mass-market software). Requirements elicitation remains problematic; missing or mistaken requirements still delay projects and cause cost overruns. No firm definition has matured for requirements elicitation in comparison to other areas of requirements engineering. This research is aimed to improve the results of the requirements elicitation process directly impacting the quality of the software products derived from them

Security-Driven Software Evolution Using A Model Driven Approach

High security level must be guaranteed in applications in order to mitigate risks during the deployment of information systems in open network environments. However, a significant number of legacy systems remain in use which poses security risks to the enterprise’ assets due to the poor technologies used and lack of security concerns when they were in design. Software reengineering is a way out to improve their security levels in a systematic way. Model driven is an approach in which model as defined by its type directs the execution of the process. The aim of this research is to explore how model driven approach can facilitate the software reengineering driven by security demand. The research in this thesis involves the following three phases. Firstly, legacy system understanding is performed using reverse engineering techniques. Task of this phase is to reverse engineer legacy system into UML models, partition the legacy system into subsystems with the help of model slicing technique and detect existing security mechanisms to determine whether or not the provided security in the legacy system satisfies the user’s security objectives. Secondly, security requirements are elicited using risk analysis method. It is the process of analysing key aspects of the legacy systems in terms of security. A new risk assessment method, taking consideration of asset, threat and vulnerability, is proposed and used to elicit the security requirements which will generate the detailed security requirements in the specific format to direct the subsequent security enhancement. Finally, security enhancement for the system is performed using the proposed ontology based security pattern approach. It is the stage that security patterns derived from security expertise and fulfilling the elicited security requirements are selected and integrated in the legacy system models with the help of the proposed security ontology. The proposed approach is evaluated by the selected case study. Based on the analysis, conclusions are drawn and future research is discussed at the end of this thesis. The results show this thesis contributes an effective, reusable and suitable evolution approach for software security

Reasoning about confidentiality at requirements engineering time

Growing attention is being paid to application security at requirements engineering time. Confidentiality is a particular subclass of security concerns that requires sensitive information to never be disclosed to unauthorized agents. Disclosure refers to undesired knowledge states of such agents. In previous work we have extended our requirements specification framework with epistemic constructs for capturing what agents may or may not know about the application. Roughly, an agent knows some property if the latter is found in the agent's memory.This paper makes the semantics of such constructs further precise through a formal model of how sensitive information may appear or disappear in an agent's memory. Based on this extended framework, a catalog of specification patterns is proposed to codify families of confidentiality requirements. A proof-of-concept tool is presented for early checking of requirements models against such confidentiality patterns. In case of violation, the counterexample scenarios generated by the tool show how an unauthorized agent may acquire confidential knowledge. Counter-measures should then be devised to produce further confidentiality requirements