Deriving security requirements from crosscutting threat descriptions

It is generally accepted that early determination of the stakeholder requirements assists in the development of systems that better meet the needs of those stakeholders. General security requirements frustrate this goal because it is difficult to determine how they affect the functional requirements of the system. This paper illustrates how representing threats as crosscutting concerns aids in determining the effect of security requirements on the functional requirements. Assets (objects that have value in a system) are first enumerated, and then threats on these assets are listed. The points where assets and functional requirements join are examined to expose vulnerabilities to the threats. Security requirements, represented as constraints, are added to the functional requirements to reduce the scope of the vulnerabilities. These requirements are used during the analysis and specification process, thereby incorporating security concerns into the functional requirements of the system

Arguing security: validating security requirements using structured argumentation

This paper proposes using both formal and structured informal arguments to show that an eventual realized system can satisfy its security requirements. These arguments, called 'satisfaction arguments', consist of two parts: a formal argument based upon claims about domain properties, and a set of informal arguments that justify the claims. Building on our earlier work on trust assumptions and security requirements, we show how using satisfaction arguments assists in clarifying how a system satisfies its security requirements, in the process identifying those properties of domains that are critical to the requirements

A framework for security requirements engineering

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

A taxonomy of asymmetric requirements aspects

The early aspects community has received increasing attention among researchers and practitioners, and has grown a set of meaningful terminology and concepts in recent years, including the notion of requirements aspects. Aspects at the requirements level present stakeholder concerns that crosscut the problem domain, with the potential for a broad impact on questions of scoping, prioritization, and architectural design. Although many existing requirements engineering approaches advocate and advertise an integral support of early aspects analysis, one challenge is that the notion of a requirements aspect is not yet well established to efficaciously serve the community. Instead of defining the term once and for all in a normally arduous and unproductive conceptual unification stage, we present a preliminary taxonomy based on the literature survey to show the different features of an asymmetric requirements aspect. Existing approaches that handle requirements aspects are compared and classified according to the proposed taxonomy. In addition,we study crosscutting security requirements to exemplify the taxonomy's use, substantiate its value, and explore its future directions

A Classification of Threats to Remote Online Examinations

This document is the Accepted Manuscript version of the following paper: Abrar Ullah, Hannah Xiao, and Trevor Barker, ‘A Classification of Threats to Remote Online Examinations’, in Proceedings of the 2016 IEEE 7th Annual Information Technology, Electronics and Mobile Communication Conference (IEMCON), 13-15 October 2016, Vancouver, Canada. Published by IEEE, available online via http://ieeexplore.ieee.org/document/7746085/ Copyright © 2016, IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Summative online examinations is a high stake process which faces many security threats. The lack of face-toface interaction, monitoring or invigilation motivates many threats, which includes intrusion by hackers and collusion by students. This paper is based on a survey of literature to present a threat classification using security abuse case scenarios. Collusion is one of the challenging threats, when a student invites a third party collaborator to impersonate or aid a student to take an online test. While mitigation of all types of threats is important, the risk of collusion is increasingly challenging because it is difficult to detect such attacks.Final Accepted Versio

Arguing satisfaction of security requirements

This chapter presents a process for security requirements elicitation and analysis, based around the construction of a satisfaction argument for the security of a system. The process starts with the enumeration of security goals based on assets in the system, then uses these goals to derive security requirements in the form of constraints. Next, a satisfaction argument for the system is constructed, using a problem-centered representation, a formal proof to analyze properties that can be demonstrated, and structured informal argumentation of the assumptions exposed during construction of the argument. Constructing the satisfaction argument can expose missing and inconsistent assumptions about system context and behavior that effect security, and a completed argument provides assurances that a system can respect its security requirements

Misalignment challenges when integrating security requirements into mobile banking application development

This study identifies and explores the core challenge faced when integrating security requirements into the mobile application software development life cycle. Studies on key issues in Information Systems (IS) have been on-going in the past decades, with security moving up the ranks of top issues in IS. Security requirements can be added into mobile application development processes by practising secure coding or by adding a third party security tool. This study gathered data from a single case study and employs grounded theory methodology to reveal misalignment as the core challenge to integrating security requirements into mobile banking application development. Identified forms of misalignment include that between security requirements and (1) external entities, (2) roles, (3) skills and (4) system requirements. Some of the findings indicate the need for further research. Research indicates that mobile application development follows agile methods for development. Agile methods have been compared with Complex Adaptive Systems (CAS). For this reason, research in IS could benefit from studies that focus on CAS as a theory to provide a better explanation on the misalignment issues in mobile application development. From the current study, the research also identified the need to address misalignment issues before embarking on a project involving integrating of security requirements

Maintaining security requirements of software systems using evolving crosscutting dependencies

Security requirements are concerned with protecting assets of a system from harm. Implemented as code aspects to weave protection mechanisms into the system, security requirements need to be validated when changes are made to the programs during system evolution. However, it was not clear for developers whether existing validation procedures such as test cases are sufficient for security and when the implemented aspects need to adapt. In this chapter, we propose an approach for detecting any change to the satisfaction of security requirements in three steps: (1) identify the asset variables in the systems that are only accessed by a join-point method; (2) trace these asset variables to identify both control and data dependencies between the non-aspect and aspect functions; and (3) update the test cases ac-cording to implementation of these dependencies to strengthen the protection when a change happens. These steps are illustrated by a case study of a meeting scheduling system where security is a critical concern

Architecting Secure Software Systems Using an Aspect-Oriented Approach: : A Survey of Current Research

The importance of security in the development of complex software systems has increasingly become more critical as software becomes increasingly more pervasive in our everyday lives. Aspect-orientation has been proposed as a means to handle the crosscutting nature of security requirements when developing, designing and implementing security-critical applications. This paper surveys some of the approaches and contributions of integrating an aspect-oriented approach into designing and implementing secure software systems

A Taxonomy Of Aspect-Oriented Security

Aspect-Oriented Programming is gaining prominence,  particularly in the area of security. There are however no taxonomies available, that classify the proliferation of research done in the area of Aspect-Oriented Security. This paper attempts to categorize research outputs conducted in this area, and evaluate the usability of the aspect-oriented paradigm in terms of software security