573,622 research outputs found

    A framework for security requirements engineering

    Get PDF
    This paper presents a framework for security requirements elicitation and analysis, based upon the construction of a context for the system and satisfaction arguments for the security of the system. One starts with enumeration of security goals based on assets in the system. These goals are used to derive security requirements in the form of constraints. The system context is described using a problem-centered notation, then this context 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 a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context, or that the context does not contain sufficient information to develop the argument. In this case, designers and architects are asked to provide additional design information to resolve the problems

    Proceedings of the 1st IEEE international workshop on evolving security and privacy requirements engineering (ESPRE 2014).

    Get PDF
    The main focus of ESPRE is to bring together practitioners and researchers interested in security and privacy requirements. ESPRE probes the interfaces between requirements engineering, security and privacy, and takes the first step in evolving security and privacy requirements engineering to meet a range of needs of stakeholders, ranging from business analysts and security engineers to technology entrepreneurs and privacy advocates. ESPRE's goal is to advance the scope of current research to consider novel approaches to the elicitation, analysis and refinement of security and privacy requirements. In particular, ESPRE fosters new visions and novel applications of requirements engineering: leveraging expertise; establishing security standards; and fusing security design, implementation and validation stages into requirements engineering. Interdisciplinary work is encouraged to investigate possibilities for aligning language and methodologies of other disciplines (e.g. legal analysis or health care procedures) with requirements engineering

    Assessing System of Systems Security Risk and Requirements with OASoSIS

    Get PDF
    When independent systems come together as a System of Systems (SoS) to achieve a new purpose, dealing with requirements conflicts across systems becomes a challenge. Moreover, assessing and modelling security risk for independent systems and the SoS as a whole is challenged by a gap in related research and approaches within the SoSs domain. In this paper, we present an approach for bridging SoS and Requirements Engineering by identifying aligning SoSs concepts to assess and model security risk and requirements. We introduce our OASoSIS approach modifying OCTAVE Allegro for SoSs using CAIRIS (Computer Aided Integration of Requirements and Information Security) with a medical evacuation (MEDEVAC) SoS exemplar for Security Requirements Engineering tool-support. Index Terms—System of Systems, Security, Risk, Human Factors, Requirements Engineering, CAIRIS

    Risk and Business Goal Based Security Requirement and Countermeasure Prioritization

    Get PDF
    Companies are under pressure to be in control of their assets but at the same time they must operate as efficiently as possible. This means that they aim to implement “good-enough security” but need to be able to justify their security investment plans. Currently companies achieve this by means of checklist-based security assessments, but these methods are a way to achieve consensus without being able to provide justifications of countermeasures in terms of business goals. But such justifications are needed to operate securely and effectively in networked businesses. In this paper, we first compare a Risk-Based Requirements Prioritization method (RiskREP) with some requirements engineering and risk assessment methods based on their requirements elicitation and prioritization properties. RiskREP extends misuse case-based requirements engineering methods with IT architecture-based risk assessment and countermeasure definition and prioritization. Then, we present how RiskREP prioritizes countermeasures by linking business goals to countermeasure specification. Prioritizing countermeasures based on business goals is especially important to provide the stakeholders with structured arguments for choosing a set of countermeasures to implement. We illustrate RiskREP and how it prioritizes the countermeasures it elicits by an application to an action case

    Guest editorial preface: special issue on Evolving security and privacy requirements engineering (ESPRE'14) 2014, Sweden.

    Get PDF
    At the Evolving Security and Privacy Requirements Engineering (ESPRE) workshop, practitioners and researchers interested in security and privacy requirements gather to discuss significant issues in the field. In particular, ESPRE participants probe the interfaces between requirements engineering, security and privacy. At ESPRE workshops, participants also take the first step in evolving security and privacy requirements engineering to meet the needs of stakeholders, ranging from business analysts and security engineers to technology entrepreneurs and privacy advocates. The most recent ESPRE workshop was held in Karlskrona, Sweden in August 2014, and was co-located with the RE 2014 conference

    Security Requirements Engineering-The Reluctant Oxymoron

    Get PDF
    Security is a focus in many systems that are developed today, yet this aspect of systems development is often relegated when the shipping date for a software product looms. This leads to problems post-implementation in terms of patches required to fix security defects or vulnerabilities. A simplistic answer is that if the code was correct in the first instance, then vulnerabilities would not exist. The reality of a complex software artefact is however, driven by other concerns. Rather than probing programs for coding errors that lead to vulnerabilities, it is perhaps more beneficial to look at the root causes of how and why vulnerabilities come to exist in software. This paper explores the reasons why this might be so, uses two simple case studies to illustrate the effects of failing to specify requirements correctly and suggests that software development methods that build in security concerns at the beginning of a project might be the way forward

    Towards the Model-Driven Engineering of Secure yet Safe Embedded Systems

    Full text link
    We introduce SysML-Sec, a SysML-based Model-Driven Engineering environment aimed at fostering the collaboration between system designers and security experts at all methodological stages of the development of an embedded system. A central issue in the design of an embedded system is the definition of the hardware/software partitioning of the architecture of the system, which should take place as early as possible. SysML-Sec aims to extend the relevance of this analysis through the integration of security requirements and threats. In particular, we propose an agile methodology whose aim is to assess early on the impact of the security requirements and of the security mechanisms designed to satisfy them over the safety of the system. Security concerns are captured in a component-centric manner through existing SysML diagrams with only minimal extensions. After the requirements captured are derived into security and cryptographic mechanisms, security properties can be formally verified over this design. To perform the latter, model transformation techniques are implemented in the SysML-Sec toolchain in order to derive a ProVerif specification from the SysML models. An automotive firmware flashing procedure serves as a guiding example throughout our presentation.Comment: In Proceedings GraMSec 2014, arXiv:1404.163

    On the Role of Primary and Secondary Assets in Adaptive Security: An Application in Smart Grids

    Get PDF
    peer-reviewedAdaptive security aims to protect valuable assets managed by a system, by applying a varying set of security controls. Engineering adaptive security is not an easy task. A set of effective security countermeasures should be identified. These countermeasures should not only be applied to (primary) assets that customers desire to protect, but also to other (secondary) assets that can be exploited by attackers to harm the primary assets. Another challenge arises when assets vary dynamically at runtime. To accommodate these variabilities, it is necessary to monitor changes in assets, and apply the most appropriate countermeasures at runtime. The paper provides three main contributions for engineering adaptive security. First, it proposes a modeling notation to represent primary and secondary assets, along with their variability. Second, it describes how to use the extended models in engineering security requirements and designing required monitoring functions. Third, the paper illustrates our approach through a set of adaptive security scenarios in the customer domain of a smart grid. We suggest that modeling secondary assets aids the deployment of countermeasures, and, in combination with a representation of assets variability, facilitates the design of monitoring function
    • …
    corecore