Security Requirements Engineering for Evolving Software Systems

Abstract

Long-lived software systems often undergo evolution over an extended period. Evolution of these systems is inevitable as they need to continue to satisfy changing business needs, new regulations and standards, and introduction of novel technologies. Such evolution may involve changes that add, remove, or modify features; or that migrate the system from one operating platform to another. These changes may result in requirements that were satisfied in a previous release of a system not being satisfied in subsequent versions. When evolutionary changes violate security requirements, a system may be left vulnerable to attacks. In this article we review current approaches to security requirements engineering and conclude that they lack explicit support for managing the effects of software evolution. We then suggest that a cross fertilization of the areas of software evolution and security engineering would address the problem of maintaining compliance to security requirements of software systems as they evolve.

Evolution of Security Engineering Artifacts

“…Several requirements engineering approaches have been proposed and they have been surveyed in (Nhlabatsi, Nuseibeh, & Yu, 2009). We categorize them in goal-oriented, problem-based and risk-based security requirements methods.…”

Maintaining Security Requirements of Software Systems Using Evolving Crosscutting Dependencies

“…Unlike the runtime-monitoring framework proposed by Salifu et al [10], in this work we concentrate on the analysis at the development time. Nhlabatsi et al [11] survey the literature on security requirements and software evolution, where the management of evolving security requirements is identified as an outstanding research issue.…”

Model-Based Argument Analysis for Evolving Security Requirements

“…Security requirements engineering: Several requirements engineering approaches for security engineering have been proposed [12], [13], and many of the approaches have been surveyed in [14], and here we briefly recall some of them to put this work into context.…”

“…ATMSystem M: " A i r T r a f f i c Management System " 9 10 O p e r a t o r B : "ATC O p e r a t o r " 11 12 O p e r a t o r − > ATMSystem : " a " 13 14 ATMSystem − > A i r c r a f t : " b " 15 16 HasWData˜> A i r c r a f t : " r " …”