Requirements and Analysis for Secure Software
Software Assurance Pocket Guide Series:
Development, Volume IV
Version 1.0, October 5, 2009
Software Assurance Pocket Guide Series:
Development, Volume IV – Version 1.0, October 5, 2009
Requirements and Analysis for Secure Software
1
Software Assurance (SwA) Pocket Guide Resources
This is a resource for „getting started‟ in selecting and adopting relevant practices for delivering secure software. As part of
the Software Assurance (SwA) Pocket Guide series, this resource is offered for informative use only; it is not intended as
directive or presented as being comprehensive since it references and summarizes material in the source documents that
provide detailed information. When referencing any part of this document, please provide proper attribution and reference
the source documents, when applicable.
This volume of the SwA Pocket Guide series focuses on requirement and analysis for secure software. It describes the
steps and knowledge required to establish the requirements and specifications for secure software, and when to apply
them during the Software Development Life Cycle (SDLC).
At the back of this pocket guide are references, limitation statements, and a listing of topics addressed in the SwA Pocket
Guide series. All SwA Pocket Guides and SwA-related documents are freely available for download via the SwA
Community Resources and Information Clearinghouse at https://buildsecurityin.us-cert.gov/swa.
Acknowledgements
SwA Pocket Guides are developed and socialized by the SwA community as a collaborative effort to obtain a common look
and feel and are not produced by individual entities. SwA Forum and Working Groups function as a stakeholder meta-
community that welcomes additional participation in advancing software security and refining. All SwA-related information
resources that are produced are offered free for public use. Inputs to documents for the online resources are invited.
Please contact Software.Assurance@dhs.gov for comments and inquiries. For the most up to date pocket guides, check
the website at https://buildsecurityin.us-cert.gov/swa/.
The SwA Forum and Working Groups are composed of government, industry, and academic members and focuses on
incorporating SwA considerations in the acquisition and development processes relative to potential risk exposures that
could be introduced by software and the supply chain.
Participants in the SwA Forum‟s Processes & Practices Working Group collaborated with the Technology, Tools and
Product Evaluation Working Group in developing the material used in this pocket guide as a step in raising awareness on
how to incorporate SwA throughout the Software Development Life Cycle (SDLC).
Software Assurance Pocket Guide Series:
Development, Volume IV – Version 1.0, October 5, 2009
Requirements and Analysis for Secure Software
2
Information contained in this pocket guide is primarily derived from the documents listed in the Resource boxes that follow
throughout this pocket guide.
Special thanks to the Department of Homeland Security (DHS), National Cyber Security Division's Software Assurance
team and Nancy Mead, who provided much of the support to enable the successful completion of this guide and related
SwA documents.
Overview
According to data presented by Fortify, the cost of correcting security flaws at the requirements level is up to 100 times less
than the cost of correcting security flaws in fielded software. Another study found that the return on investment (ROI) when
security analysis and secure engineering practices are introduced early in the development cycle ranges from 12 to 21
percent, with the highest rate of return occurring when the analysis is performed during application design. Regardless of
the data or study presented, the costs of correcting secure flaws are more expensive to repair or patch the later in the
Software Development Life Cycles (SDLC) than those flaws are identified earlier in the SDLC.
Comprehensive requirements are critical for successful system development, but all too often, requirements fail to explicitly
consider security. As a result, systems meet the functionality but are rarely safe and consequently are the victim of
attacks. Systems which carefully document security requirements reduce the likelihood of successful attacks. Security
requirements include functions that implement a security policy such as areas of access control, identification,
authentication and authorization, and other functions that perform encryption, decryption, and key management. These
functions prevent the violation of the security properties of the system or the information it processes, such as unauthorized
access, modification, denial of service, disclosure, etc. Security requirements which are testable, complete, unambiguous
and measureable will produce more secure software.
The material in this guide approaches requirements from a security perspective. It is assumed that the reader is already
familiar with the process of functional software requirements development. Several approaches to security requirements
engineering are described in this pocket guide and references are provided for additional material that can help ensure that
an organization‟s products effectively meet security requirements.
Resources
» “Requirements Engineering”, Nancy R. Mead, DHS Build Security In (BSI) portal at
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/requirements.html.
» “Software Security Assurance: A State-of-the-Art Report”, Goertzel, Karen Mercedes, et al, Information
Assurance Technology Analysis Center (IATAC) of the DTIC at
http://iac.dtic.mil/iatac/download/security.pdf .
» Nancy R. Mead, et al, “Software Security Engineering: A Guide for Project Managers.” Upper Saddle
River, New Jersey: Addison-Wesley, 2008.
» “Microsoft Security Development Lifecycle (SDL) – Process Guidance” at
http://msdn.microsoft.com/en-us/library/84aed186-1d75-4366-8e61-8d258746bopq.aspx.
Software Assurance Pocket Guide Series:
Development, Volume IV – Version 1.0, October 5, 2009
Requirements and Analysis for Secure Software
3
The Need for Requirements
Most vulnerabilities and weaknesses in software systems can be traced to inadequate or incomplete requirements or
requirements that fail to specify the functions, constraints, and non-functional properties of the software. Software must be
dependable, trustworthy, and resilient. If software cannot satisfy these three needs (reliability, trustworthiness, and
resiliency) it is of dubious value. Thus, these three needs should be addressed by all of the requirements for the software‟s
functionality, behaviors, and constraints.
Requirements engineering is critical to the success of any major
software development project. Studies have shown that requirements
engineering defects cost 10 to 200 times as much to correct once
fielded than if they were detected during requirements development.
Other studies have shown that reworking requirements, design, and
code defects on most software development projects costs 40 to 50
percent of total project effort, and the percentage of defects originating
during requirements engineering is estimated at more than 50 percent.
According to data presented by Fortify, the cost of correcting security
flaws at the requirements level is up to 100 times less than the cost of
correcting security flaws in fielded software. A prior study found that
the return on investment (ROI) when security analysis and secure engineering practices are introduced early in the
development cycle ranges from 12 to 21 percent, with the highest rate of return occurring when the analysis is performed
during application design. The National Institute of Standards and Technology (NIST) reports software that is faulty in
security and reliability costs the economy $59.5 billion annually in breakdowns and repairs. David Rice, former NSA
cryptographer and author of Geekonomics: The Real Cost of Insecure Software, approximates that the total economic
cost of security flaws is around US $180 billion a year, as reported on Forbes.com. The costs of poor security
requirements show that even a small improvement in this area would provide a high value. By the time that an application
is fielded and in its operational environment, it is very difficult and expensive to significantly improve its overall security.
Requirements Development
Software requirements by and large are often thought of as requirements for
functionality, and in some cases, they are requirements for performance
constraints (i.e., the system must have five inputs). They tend to be expressed
in positive terms. The Guide to the Software Engineering Body of Knowledge
(SWEBOK) defines a software requirement as “a property which must be
exhibited in order to solve some problem in the real world.” Traditional software
requirements express the needs and constraints placed on a software product
that contribute to the solution of some real-world problem.
On-line Resources
» Nancy R Mead, “Security Requirements Engineering”, Build Security In (BSI) portal at
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/requirements/243-BSI.html.
» Barmak Meftah, “Business Software Assurance Identifying and Reducing Software Risk in the Enterprise” at
https://buildsecurityin.us-cert.gov/swa/downloads/Meftah.pdf.
Inadequate or Incomplete
Requirements Side-effects:
» Projects significantly over budget,
» Projects severely overdue,
» Projects cancellation,
» Project significant scope reduction,
» Poor quality end product, and
» Rarely used product.
Well-specified
Requirements Attributes:
» Testable,
» Complete,
» Unambiguous, and
» Measurable.
Software Assurance Pocket Guide Series:
Development, Volume IV – Version 1.0, October 5, 2009
Requirements and Analysis for Secure Software
4
There is no single definition for software security requirements. Software security requirements tend to be either
constraints on functionality or a statement of a needed property or attribute that will be manifested by the software
behavior. Charles Haley et al, propose representing security requirements as crosscutting threat descriptions that end up
being defined as a set of constraints on the functional requirements. These constraints are the “security requirements.” At
least initially during requirements capture, security requirements are often stated in negative terms.
There is extensive work on requirements development, as well as tools and techniques to support the processes.
Unfortunately, most of the work fails to explicitly consider security. Work that does is usually concerned with security
requirements in the sense of requirements
development for the security functionality in
a system, such as access controls. A large
portion of requirements
development research and
practice addresses the capabilities
that the system will provide from
the user‟s perspective, while little
attention is given to what the
system should not do. Users have
implicit assumptions for the
software applications and systems
that they use. They expect them
to be secure and are surprised
when they are not. These user
assumptions need to be translated
into security requirements for the
software systems while they are
under development. Often the
implicit assumptions of users are overlooked and the features become the main focus instead. Figure 1 provides an
example of additional activities (white background boxes) for increasing software security superimposed over the generic
requirements development process.
Another important perspective is that of the attacker. The attacker is not particularly interested in functional features of the
system, unless they provide an avenue for attack. The attacker typically looks for defects and other conditions outside the
norm that will allow a successful attack to take place. It‟s important for requirements developers to think about the
attacker‟s perspective and not just the functionality of the system from the end-user‟s perspective. A discussion of attack
patterns can be found in Chapter 2 of the Software Security Engineering: A Guide for Project Managers. Detailed articles
and cataloged attack patterns can be found at the BSI and Common Attack Pattern Enumeration and Classification
(CAPEC) portals listed on the following resource box.
Other techniques that can be used in defining the attacker‟s perspective are misuse and abuse cases, attack trees and
threat modeling. Security requirements are often stated as negative requirements. As a result, general security
requirements, such as “The system shall not allow successful attacks,” are usually not feasible, as there is no consensus
on ways to validate them other than to apply formal methods to the entire system. However, essential services and assets
that must be protected can be identified. Operational usage scenarios can be extremely helpful aids to understanding
which services and assets are essential. By providing threads that trace through the system, operational usage scenarios
also help to highlight security requirements, as well as other quality requirements such as safety and performance. Once
the essential services and assets are understood, an organization is able to validate that mechanisms such as access
control, levels of security, backups, replication, and policy are implemented and enforced. One can also validate that the
system properly handles specific threats identified by a threat model and correctly responds to intrusion scenarios.
Figure 1 – Secure Requirements Additions to the
Functional Requirement Process
Software Assurance Pocket Guide Series:
Development, Volume IV – Version 1.0, October 5, 2009
Requirements and Analysis for Secure Software
5
Requirements Elicitation
Requirements elicitation is the process that addresses where requirements come from and how to collect them
(SWEBOK). Using an elicitation method can help in producing a consistent and complete set of security requirements.
However, ordinary functional (end-user) elicitation methods such as scenarios, interviews, etc. may not result in a
consistent and complete set of security requirements. When security requirements are elicited in a systematic way, the
resulting system is likely to have fewer security exposures.
This section provides an overview of a number of elicitation methods and tradeoff analysis to select a suitable one.
Companion case studies by Nancy R. Mead can be found at the BSI portal. While results may vary from one organization
to another, the discussion of the selection process and various methods should be of general use. Requirements
elicitation is an active research area, and is expected to see advances in the future. The expectation within the community
is that eventually there will be studies measuring which methods are most effective for eliciting security requirements. At
present, however, there is little if any data comparing the effectiveness of different methods for eliciting security
requirements.
The following list identifies several methods that could be considered for eliciting security requirements. A description on
misuse cases and threat modeling is provided next. For details on the other methods please visit the BSI portal.
» Misuse/Abuse Cases
» Threat Analysis
» Soft Systems Methodology
» Quality Function Deployment
» Controlled Requirements Expression
» Issue-based Information Systems
» Joint Application Development
» Feature-oriented Domain Analysis
» Critical Discourse Analysis
» Accelerated Requirements Method
On-line Resources
» IEEE Computer Society,”Guide to the Software Engineering Body of Knowledge (SWEBOK)” at
http://www2.computer.org/portal/web/swebok.
» Attack Patterns, Build Security In (BSI) portal at
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/attack.html.
» Common Attack Pattern Enumeration and Classification (CAPEC) at http://capec.mitre.org/.
» Charles B. Haley, et al, “Deriving Security Requirements From Crosscutting Threat Descriptions”, at
http://mcs.open.ac.uk/cbh46/papers/AOSD04.pdf.
Software Assurance Pocket Guide Series:
Development, Volume IV – Version 1.0, October 5, 2009
Requirements and Analysis for Secure Software
6
Misuse/Abuse Cases – Misuse cases are
similar to use cases, except that they are
meant to detail common attempted abuses of
the system. Like use cases, misuse cases
require understanding the services that are
present in the system. A use case generally
describes behavior that the system owner
wants the system to show. Misuse cases
apply the concept of a negative scenario –
that is, a situation that the system's owner
does not want to occur. Misuse cases are
also known as abuse cases. For an in-depth
view of misuse cases, see Gary McGraw‟s
“Misuse and Abuse Cases: Getting Past the
Positive” at the BSI portal.
Misuse cases can help organizations begin
to see their software in the same light that attackers do. As use-case models have proven quite helpful for the functional
specification of requirements, a combination misuse cases and use cases could improve the efficiency of eliciting all
requirements in a system engineering life cycle. Guttorm Sindre and Andreas Opdahl extended use-case diagrams with
misuse cases to represent the actions that systems should prevent in tandem with those that they should support for
security and privacy requirement. There are several templates for misuse and abuse cases provided by Sindre and
Opdahl, and Alexander. Figure 2 is an example of a use/misuse case diagram from Alexander‟s paper. The high-level
case is shown above. Alexander indicated that Misuse and Use Cases may be developed in stages; going from system to
subsystem levels and lower as necessary. Lower-level cases may highlight aspects not considered at higher levels,
possibly forcing re-analysis. The approach is not rigidly top-down but offers rich possibilities for exploring, understanding,
and validating the requirements in any direction.
Use cases describe system behavior in terms of functional (end-user) requirements. Misuse cases and use cases may be
developed from system to subsystem levels – and lower as necessary. Lower level cases may draw attention to
underlying problems not considered at higher levels and may compel system engineers to reanalyze the system design.
Misuse cases are not a top-down method, but they provide opportunities to investigate and validate the security
requirements necessary to accomplish the system's mission.
As with normal use cases, one should expect misuse cases to require adjustment over time. Particularly, it is common to
start with high-level misuse cases, and refine them as the details of the system are better understood. Determining misuse
cases generally constitutes an informed brainstorming activity among a team of security and reliability experts. In practice,
the team of experts asks questions of a system‟s designers to help identify the places where the system is likely to have
weaknesses by assuming the role of an attacker and thinking like an attacker would. Such brainstorming involves a careful
look at all user interfaces (including environmental factors) and considers events that developers assume a person can‟t or
won‟t do. There are three good starting points for structured brainstorming:
» First,
本文档为【RequirementsMWV1001AM091111】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑,
图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。