Security requirements engineering-the reluctant oxymoron

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.