liu.seSearch for publications in DiVA
Change search
CiteExportLink to record
Permanent link

Direct link
Cite
Citation style
  • apa
  • harvard1
  • ieee
  • modern-language-association-8th-edition
  • vancouver
  • oxford
  • Other style
More styles
Language
  • de-DE
  • en-GB
  • en-US
  • fi-FI
  • nn-NO
  • nn-NB
  • sv-SE
  • Other locale
More languages
Output format
  • html
  • text
  • asciidoc
  • rtf
The Impact of Neglecting Domain-Specific Security and Privacy Requirements
Linköping University, Department of Computer and Information Science, PELAB - Programming Environment Laboratory. Linköping University, The Institute of Technology.
Linköping University, Department of Computer and Information Science, PELAB - Programming Environment Laboratory. Linköping University, The Institute of Technology.
2007 (English)In: Proceedings of the 12th Nordic Workshop on Secure IT Systems (Nordsec 2007), 2007Conference paper, Published paper (Other academic)
Abstract [en]

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 are the reasons for the inconsistencies, and what is 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.

Place, publisher, year, edition, pages
2007.
Keyword [en]
security and privacy requirements, requirements engineering
National Category
Computer Science
Identifiers
URN: urn:nbn:se:liu:diva-90026OAI: oai:DiVA.org:liu-90026DiVA: diva2:611268
Conference
The 12th Nordic Workshop on Secure IT Systems (Nordsec 2007), October 11-12, 2007, Reykjavik, Iceland
Available from: 2013-03-15 Created: 2013-03-15 Last updated: 2013-03-25
In thesis
1. Contributions to Specification, Implementation, and Execution of Secure Software
Open this publication in new window or tab >>Contributions to Specification, Implementation, and Execution of Secure Software
2013 (English)Doctoral thesis, comprehensive summary (Other academic)
Abstract [en]

This thesis contributes to three research areas in software security, namely security requirements and intrusion prevention via static analysis and runtime detection.

We have investigated current practice in security requirements by doing a field study of eleven requirement specifications on IT systems. The conclusion is that security requirements are poorly specified due to three things:  inconsistency in the selection of requirements, inconsistency in level of detail, and almost no requirements on standard security solutions. A follow-up interview study addressed the reasons for the inconsistencies and the impact of poor security requirements. It shows that the projects had relied heavily on in-house security competence and that mature producers of software compensate for poor requirements in general but not in the case of security and privacy requirements specific to the customer domain.

Further, we have investigated the effectiveness of five publicly available static analysis tools for security. The test results show high rates of false positives for the tools building on lexical analysis and low rates of true positives for the tools building on syntactical and semantical analysis. As a first step toward a more effective and generic solution we propose decorated dependence graphs as a way of modeling and pattern matching security properties of code. The models can be used to characterize both good and bad programming practice as well as visually explain code properties to programmers. We have implemented a prototype tool that demonstrates how such models can be used to detect integer input validation flaws.

Finally, we investigated the effectiveness of publicly available tools for runtime prevention of buffer overflow attacks. Our initial comparison showed that the best tool as of 2003 was effective against only 50 % of the attacks and there were six attack forms which none of the tools could handle. A follow-up study includes the release of a buffer overflow testbed which covers 850 attack forms. Our evaluation results show that the most popular, publicly available countermeasures cannot prevent all of these buffer overflow attack forms.

Place, publisher, year, edition, pages
Linköping: Linköping University Electronic Press, 2013. 249 p.
Series
Linköping Studies in Science and Technology. Dissertations, ISSN 0345-7524 ; 1503
National Category
Engineering and Technology
Identifiers
urn:nbn:se:liu:diva-88330 (URN)978-91-7519-681-7 (ISBN)
Public defence
2013-04-22, Visionen, hus B, Campus Valla, Linköpings universitet, Linköping, 13:15 (English)
Opponent
Supervisors
Available from: 2013-03-15 Created: 2013-02-01 Last updated: 2017-03-28Bibliographically approved

Open Access in DiVA

No full text

Authority records BETA

Wilander, JohnGustavsson, Jens

Search in DiVA

By author/editor
Wilander, JohnGustavsson, Jens
By organisation
PELAB - Programming Environment LaboratoryThe Institute of Technology
Computer Science

Search outside of DiVA

GoogleGoogle Scholar

urn-nbn

Altmetric score

urn-nbn
Total: 138 hits
CiteExportLink to record
Permanent link

Direct link
Cite
Citation style
  • apa
  • harvard1
  • ieee
  • modern-language-association-8th-edition
  • vancouver
  • oxford
  • Other style
More styles
Language
  • de-DE
  • en-GB
  • en-US
  • fi-FI
  • nn-NO
  • nn-NB
  • sv-SE
  • Other locale
More languages
Output format
  • html
  • text
  • asciidoc
  • rtf