Title

Security requirements engineering-the reluctant oxymoron

Document Type

Conference Proceeding

Publisher

School of Computer and Information Science, Edith Cowan University

Faculty

Computing, Health and Science

School

Computer and Security Science, Centre for Security Research

RAS ID

8796

Comments

Originally published as: Johnstone, M. N. (2009, December). Security requirements engineering-the reluctant oxymoron. In Australian Information Security Management Conference (p. 5). Original article available here

Abstract

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.

DOI

10.4225/75/57b4011e30de8

 
COinS
 

Link to publisher version (DOI)

10.4225/75/57b4011e30de8