DOC PREVIEW
GU GCIS 504 - Specifying Reusable Security Requirements

This preview shows page 1-2-3-4-5 out of 15 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2004 Vol. 3, No. 1, January-February 2004 Cite this column as follows: Donald Firesmith: “Specifying Reusable Security Requirements”, in Journal of Object Technology, vol. 3, no. 1, January-February 2004, pp. 61-75. http://www.jot.fm/issues/issue_2004_01/column6 Specifying Reusable Security Requirements Donald Firesmith, Software Engineering Institute, U.S.A. Abstract Unlike typical functional requirements, security requirements can potentially be highly reusable, especially if specified as instances of reusable templates. In this column, I will discuss the concepts underlying security engineering including its quality subfactors. I will then address the issue of security requirements and how they differ from the architectural mechanisms that will fulfill them. Then, I will discuss the value of reusable parameterized templates for specifying security requirements and provide an example of such a template and its associated usage. Finally, I will outline an asset-based risk-driven analysis approach for determining the appropriate actual parameters to use when reusing such parameterized templates to specify security requirements. 1 CONCEPTS UNDERLYING SECURITY ENGINEERING To specify security requirements, it is critical to first understand the concepts underlying security engineering. And the most important concept of these is ‘security’ itself. Whereas security is often defined as an incomplete subset of its most important quality subfactors (e.g., integrity and privacy), the following figure illustrates that a more general and complete definition of security is that it is the degree to which malicious1 (i.e., unauthorized and intentional) harm to valuable system assets is prevented, reduced, and properly responded to. Thus, security is about protecting these assets (e.g., data, services, hardware, and personnel) from harm due to various kinds of attacks (e.g., password sniffing, spoofing, viruses) that may be mounted by the various kinds of attackers (e.g., hackers, crackers, disgruntled employees, international cyber-terrorists, industrial spies, governmental spies, foreign military, etc.). These assets are at risk due both to various kinds of threats (e.g., theft, vandalism, unauthorized disclosure, destruction, fraud, extortion, espionage, trespass, etc.) of attack as well as the vulnerabilities the system may 1 Some may argue that the term ‘malicious’ is too strong. What about people who vandalize the website of a company that pollutes the environment? What about someone who uses company computers to surf the Web in violation of company policy. The first example is a cybercrime and the second is an unauthorized use of property. In both cases, the victims would be justified to consider these acts malicious. If the term ‘malicious’ still seems too harsh, just consider it to mean the combination of unauthorized and intentional.SPECIFYING REUSABLE SECURITY REQUIREMENTS 62 JOURNAL OF OBJECT TECHNOLOGY VOL. 3, NO. 1 have. Security requirements are engineered to specify the system’s security policies and both policies and requirements should address these security risks. Security mechanisms (e.g., user IDs, passwords, encryption, firewalls, antivirus software, intrusion detection systems, etc.) are then architected to fulfill the security requirements. Some of these concepts influence the engineering of security requirements (e.g., policies, risks, threats, and assets), whereas others (e.g., security mechanisms, security vulnerabilities, and attacks) are influenced by the security requirements. Fig. 1: Concepts that Influence and are Influenced by Security Requirements The following list defines these security-oriented terms that will be used during the remainder of this column:VOL. 3, NO. 1 JOURNAL OF OBJECT TECHNOLOGY 63 • Asset is anything of value that should be protected from harm. An asset can require protection because it is the potential target of attack. Assets can be people, properties (e.g., data, hardware, software, and facilities), and services. • Attack (a.k.a., security breach) is an attacker’s unauthorized attempt to cause harm to an asset (i.e., violate the security of the system, bypass security mechanisms). An attack may be either successful or unsuccessful.2 • Attacker is an agent (e.g., humans, programs, processes, devices, or other systems) that causes an attack due to the desire to cause harm to an asset. • Harm is a negative impact associated with an asset due to an attack. • Threat is a general condition, situation, or state (typically corresponding to the motivation of potential attackers) that may result in one or more related attacks.3 • Security is the degree to which malicious harm to a valuable asset is prevented, reduced, and properly responded to. Security is thus the quality factor that signifies the degree to which valuable assets are protected from significant threats posed by malicious attackers. • Security Goal is a quality goal that documents a target level of security or one of its subfactors [Lamsweerde 2000]. • Security Policy is a quality policy that mandates a system-specific4 quality criterion for security or one of its subfactors. • Security Mechanism (a.k.a., countermeasure) is an architecture mechanism (i.e., strategic decision) that helps fulfill one or more security requirements and/or reduces one or more security vulnerabilities. Security mechanisms can be implemented as some combination of hardware or software components, manual procedures, training, etc. • Security Requirement is a quality requirement that specifies a required amount of security (actually a quality subfactor of security) in terms of a system-specific criterion and a minimum level of an associated quality measure that is necessary to meet one or more security policies. • Security Risk is the potential risk of harm to an asset due to the sum (over all relevant threats) of the negative impact of the harm to the asset (i.e., its criticality) multiplied by the likelihood of the harm occurring5. 2 Due to their malicious nature, most attacks are cybercrimes, which are crimes (e.g., theft of money or services, fraud, espionage, extortion, vandalism, terrorism, child pornography, etc.) carried out using computer resources. However, some unauthorized misuses of software-intensive


View Full Document

GU GCIS 504 - Specifying Reusable Security Requirements

Download Specifying Reusable 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 Specifying Reusable 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 Specifying Reusable 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?