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.
TopSecurity Goals And Requirements
The main system security goals to achieve are confidentiality, integrity, availability, and accountability. Confidentiality ensures that only authorized users or applications are allowed to interact with the system. Integrity ensures that critical data has not been changed in an improper way in the system. Availability ensures that the information and/or services are readily available to an authorized user on demand. Accountability ensures that once authorized users access the system, they are accountable for all of their actions (Whitman & Mattord, 2005). Normally, security requirements should not be specified in terms of the types of security mechanisms or controls that are currently used for implementation. To achieve the security goals, security requirements should be identified. These requirements can be structured around the 12 security requirement types identified in Firesmith (2003).
Key Terms in this Chapter
Security Engineering Process: The security engineering process is the process of embedding system security starting from security requirements elicitation and ending with security implementation testing.
Non-Functional Requirement: A non-functional requirement is a system feature that is not directly visible to the system users. However, it may have an impact of the quality of the visible system features of functional requirements.
Functional Requirement: A functional requirement is a system feature or functionality that is directly visible to external system users.
Security Requirement: A security requirement is a security feature required by system users or a quality the system must possess to increase the users trust in the system they use. In general, a security requirement is considered as a non-functional requirement.
Trust: Trust is a relative user’s perception of the degree of confidence the user has in the system he/she uses.
Trustworthy System: A trustworthy system is a system that gains a high level of trust by its users by satisfying the specified security, privacy, safety, availability and business integrity requirements.