GU GCIS 504 - Engineering Security Requirements

Unformatted text preview:

JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2003 Vol. 2, No. 1, January-February 2003 Cite this column as follows: Donald Firesmith: Engineering Security Requirements, in Journal of Object Technology, vol. 2, no. 1, January-February 2003, pages 53-68. http://www.jot.fm/issues/issue_2003_01/column6 Engineering Security Requirements Donald G. Firesmith, Firesmith Consulting, U.S.A. Abstract Most requirements engineers are poorly trained to elicit, analyze, and specify security requirements, often confusing them with the architectural security mechanisms that are traditionally used to fulfill them. They thus end up specifying architecture and design constraints rather than true security requirements. This article defines the different types of security requirements and provides associated examples and guildlines with the intent of enabling requirements engineers to adequately specify security requirements without unnecessarily constraining the security and architecture teams from using the most appropriate security mechanisms for the job. 1 SECURITY REQUIREMENTS The engineering of the requirements for a business, system or software application, component, or (contact, data, or reuse) center involves far more than merely engineering its functional requirements. One must also engineer its quality, data, and interface requirements as well as its architectural, design, implementation, and testing constraints. Whereas some requirements engineers might remember to elicit, analyze, specify, and manage such quality requirements as interoperability, operational availability, performance, portability, reliability, and usability, many are at a loss when it comes to security requirements. Most requirements engineers are not trained at all in security, and the few that have been trained have only been given an overview of security architectural mechanisms such as passwords and encryption rather than in actual security requirements. Thus, the most common problem with security requirements, when they are specified at all, is that they tend to be accidentally replaced with security-specific architectural constraints that may unnecessarily constrain the security team from using the most appropriate security mechanisms for meeting the true underlying security requirements. This article will help you distinquish between security requirements and the mechanisms for achieving them, and will provide you with good examples of each type of security requirement. In today’s world of daily virus alerts, malicious crackers, and the threats of cyber-terrorism, it would be well to remember the following objectives of security requirements:ENGINEERING SECURITY REQUIREMENTS 54 JOURNAL OF OBJECT TECHNOLOGY VOL. 2, NO. 1 • Ensure that users and client applications are identified and that their identities are properly verified. • Ensure that users and client applications can only access data and services for which they have been properly authorized. • Detect attempted intrusions by unauthorized persons and client applications. • Ensure that unauthorized malicious programs (e.g., viruses) do not infect the application or component. • Ensure that communications and data are not intentionally corrupted. • Ensure that parties to interactions with the application or component cannot later repudiate those interactions. • Ensure that confidential communications and data are kept private. • Enable security personnel to audit the status and usage of the security mechanisms. • Ensure that applications and centers survive attack, possibly in degraded mode. • Ensure that centers and their components and personnel are protected against destruction, damage, theft, or surreptitious replacement (e.g., due to vandalism, sabotage, or terrorism). • Ensure that system maintenance does not unintentionally disrupt the security mechanisms of the application, component, or center. To meet the above objectives, we will briefly address each of the following corresponding kinds of security requirements: • Identification Requirements • Authentication Requirements • Authorization Requirements • Immunity Requirements • Integrity Requirements • Intrusion Detection Requirements • Nonrepudiation Requirements • Privacy Requirements • Security Auditing Requirements • Survivability Requirements • Physical Protection Requirements • System Maintenance Security Requirements Guidelines The following guidelines have proven useful with eliciting, analyzing, specifying, and maintaining security requirements: • Security Policy A security requirement is typically a detailed requirement that implements an overriding security policy.SECURITY REQUIREMENTS VOL. 2, NO. 1 JOURNAL OF OBJECT TECHNOLOGY 55 • Correctness Requirements Security requirements depend on correctness requirements because implementation defects are often bugs that produce security vulnerabilities. Thus, using a type-unsafe languages such as C can result in array boundary defects that can be exploited to run malicious scripts. • Feasibility It is impossible to build a 100% secure business, application, component, or center. Increasing security typically: o Increases the associated cost. o Increases the associated schedule. o Decreases the associated usability. • Misuse Cases Whereas functional requirements are now typically specified as use cases, traditional narrative English language security requirements can often be analyzed, refined, and thus further specified as misuse or abuse cases [Sindre and Opdahl 2001] [Alexander2003] whereby: o The user client external (human actor or application) of a use case is replaced by a misuser (e.g., cracker or disgruntled employee) who attempts to violate the security of an application, component, or center. o The normal user-initiated interactions of the user case are replaced by the misuser-initiated attack interactions of the misuse case. o The required application or component response interactions and postconditions of the user case are replaced by the required application or component security-oriented responses and postconditions of the misuse case. o Note that whereas goals drive use case requirements, threats drive misuse case requirements. o Note also that a very common problem with using misuse cases as a requirements approach is that they often assume the prior existance


View Full Document

GU GCIS 504 - Engineering Security Requirements

Download Engineering Security Requirements
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Engineering Security Requirements and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Engineering Security Requirements 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?