Abstract

To increase users’ trust in the systems they use, there is a need to develop trustworthy systems. These systems must meet the needs of the system’s stakeholders with respect to security, privacy, reliability, and business integrity (Mundy, deVries, Haynes, & Corwine, 2002). The first major step in achieving trustworthiness is to properly and faithfully capture the stakeholders requirements. A requirement is something that the system must satisfy or a quality that the system must possess. A requirement is normally elicited from the system stakeholders, including its users, developers, and owners. Requirements should be specified before attempting to construct the system. If the correct requirements are not captured properly and faithfully, the correct system cannot be built. Consequently, the system will not be usable by its intended users. The success of any system depends on meeting requirements classified under two complementary types. First, the functional requirements are the system’s operations from the user’s perspective describing the visible and external interactions with the system under consideration. Second, the non-functional requirements (NFRs) are mainly the system’s constraints imposing special conditions and qualities on the system to construct. Consequently, system acceptance testing must be based on both functional and non-functional system’s requirements. Unfortunately, it is reported that about 60% of errors originate from the requirements and analysis activities (Weinberg, 1997).

Surveys have shown that large numbers of IT-based systems were implemented starting from their elicited functional requirements without a clear and formal consideration of their non-functional counterparts such as security requirements. Furthermore, system requirements engineers and analysts are not well-trained in capturing security requirements early in the system development process. Security assurances are often based on the traditional and ad hoc approach of conducting penetration tests followed by a patching process. This approach is very costly and endangers the fulfillment of the basic goals of system security, namely confidentiality, integrity, availability, and accountability. Recently, many researchers addressed security requirements engineering as an integral and essential element of systems engineering. Devanbu and Stubblebine (2000) propose a roadmap for software engineering for security, and Henning and Garner (1999) consider life cycle models for survivable and secure systems.

Non-functional requirements can be classified under three broad categories (Robertson & Robertson, 1999): system-related, process and project-related and humanrelated requirements.

The rest of this article is organized as follows. The next section overviews the security goals and requirements. The third section introduces security requirements modeling using the Goal-Oriented Requirements Language (GRL) (ITU, 2002) and UMLsec, a security extension to the Unified Modeling Language (Jurjens, 2005; Elshahry, 2005), and its modifications. The fourth section provides some examples of using GRL and UMLsec models for requirements specifications. We conclude in the final section and provide items for further investigation.

-- DanielAmyot - 05 Jul 2010

Discussion

FormForVirtualLibrary edit

Title Modeling Security Requirements for Trustworthy Systems
Authors K. Saleh and G. Elshahry
Type Book
Conference/Journal Title Encyclopedia of Information Science and Technology
Volume/Number Second Edition
Editors M. Khosrow-Pour
Publisher IGI Global
Month -
Year 2009
Pages 2657-2664
DOI 10.4018/978-1-60566-026-4.ch424
Keywords Security, Goal-oriented Requirement Language, GRL, NFR, UML, UMLSec
Topic revision: r1 - 05 Jul 2010, DanielAmyot
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback