We conducted oral, open-question interviews with
the customer project leaders. The interviews lasted 1-
2 hours and were recorded and transcribed (approximately
30 pages of text per interview) to allow for an
accurate, qualitative analysis. We chose to interview
the project leaders since they had a good overview of
the requirements process, of the systems and of relations
with the producers.
The three systems were chosen specifically because
they were all security and privacy critical, they
were fairly large, and they represented three interesting
categories—a standard system with configuration
(Health Care 1), a combination of standard components
and development (Highway Tolls), and one system
completely built from scratch (Medical Advice).
Further, these systems had some of the best security
requirements in the previous study (in the case of the
Highway Tolls system there were proper references to
security standards) which hopefully would work as an
upper bound on our analysis, i.e. the other systems
were unlikely to show substantially better results when
verified against our hypotheses.
The systems were built byWM-data (Swedish company
with 9.000 employees, now part of LogicaCMG),
IBM, and Cap Gemini. We have chosen not say which
company delivered which system, and the customers
asked us not to publish man hours or code size since
such figures were considered business secrets.
Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
| File | MIME type | Size (KB) | Language | Download | |
|---|---|---|---|---|---|
| paper_nordsec07_wilander_gustavsson.pdf | application/pdf | 82.44 KB | English | DOWNLOAD! |
Provides definitions
Abstract
In a previous field study of eleven software projects including e-business, health care and military applications we documented current practice in security requirements. The overall conclusion of the study was that security requirements are poorly and inconsistently specified. However, two important questions remained open; what were the reasons for the inconsistencies,
and what was the impact of such poor security requirements? In this paper we seek the answers by performing in-depth interviews with three of the customers from the previous study. The interviews show that mature producers of software (in this case IBM, Cap Gemini, and WM-Data) compensate for poor requirements in areas within their expertise, namely software
engineering. But in the case of security and privacy requirements specific to the customer domain, such compensation is not found. In all three cases this has led to security and/or privacy flaws in the systems. Our conclusion is that special focus needs to be put on domain-specific security and privacy needs when eliciting
customer requirements.