Software Security Engineering: A Guide for Project Managers / Edition 1

by Julia Allen, Sean Barnum, Robert Ellison, Gary McGraw, Nancy Mead

Overview

“This book’s broad overview can help an organization choose a set of processes, policies, and techniques that are appropriate for its security maturity, risk tolerance, and development style. This book will help you understand how to incorporate practical security techniques into all phases of the development lifecycle.”

—Steve Riley, senior security strategist, Microsoft Corporation

“There are books written on some of the topics addressed in this book, and there are other books on secure systems engineering. Few address the entire life cycle with a comprehensive overview and discussion of emerging trends and topics as well as this one.”

—Ronda Henning, senior scientist-software/security queen, Harris Corporation

Software that is developed from the beginning with security in mind will resist, tolerate, and recover from attacks more effectively than would otherwise be possible. While there may be no silver bullet for security, there are practices that project managers will find beneficial. With this management guide, you can select from a number of sound practices likely to increase the security and dependability of your software, both during its development and subsequently in its operation.

Software Security Engineering draws extensively on the systematic approach developed for the Build Security In (BSI) Web site. Sponsored by the Department of Homeland Security Software Assurance Program, the BSI site offers a host of tools, guidelines, rules, principles, and other resources to help project managers address security issues in every phase of the software development life cycle (SDLC). The book’s expert authors, themselves frequent contributors to the BSI site, represent two well-known resources in the security world: the CERT Program at the Software Engineering Institute (SEI) and Cigital, Inc., a consulting firm specializing in software security.

This book will help you understand why

• Software security is about more than just eliminating vulnerabilities and conducting penetration tests
• Network security mechanisms and IT infrastructure security services do not sufficiently protect application software from security risks
• Software security initiatives should follow a risk-management approach to identify priorities and to define what is “good enough”—understanding that software security risks will change throughout the SDLC
• Project managers and software engineers need to learn to think like an attacker in order to address the range of functions that software should not do, and how software can better resist, tolerate, and recover when under attack

Chapter 1: Why Is Security a Software Issue? 1

1.1 Introduction 1

1.2 The Problem 2

1.3 Software Assurance and Software Security 6

1.4 Threats to Software Security 9

1.5 Sources of Software Insecurity 11

1.6 The Benefits of Detecting Software Security Defects Early 13

1.7 Managing Secure Software Development 18

1.8 Summary 23

Chapter 2: What Makes Software Secure? 25

2.1 Introduction 25

2.2 Defining Properties of Secure Software 26

2.3 How to Influence the Security Properties of Software 36

2.4 How to Assert and Specify Desired Security Properties 61

2.5 Summary 71

Chapter 3: Requirements Engineering for Secure Software 73

3.1 Introduction 73

3.2 Misuse and Abuse Cases 78

3.3 The SQUARE Process Model 84

3.4 SQUARE Sample Outputs 91

3.5 Requirements Elicitation 99

3.6 Requirements Prioritization 106

3.7 Summary 112

Chapter 4: Secure Software Architecture and Design 115

4.1 Introduction 115

4.2 Software Security Practices for Architecture and Design: Architectural Risk Analysis 119

4.3 Software Security Knowledge for Architecture and Design: Security Principles, Security Guidelines, and Attack Patterns 137

4.4 Summary 148

Chapter 5: Considerations for Secure Coding and Testing 151

5.1 Introduction 151

5.2 Code Analysis 152

5.3 Coding Practices 160

5.4 Software Security Testing 163

5.5 Security Testing Considerations Throughout the SDLC 173

5.6 Summary 180

Chapter 6: Security and Complexity: System Assembly Challenges 183

6.1 Introduction 183

6.2 Security Failures 186

6.3 Functional and Attacker Perspectives for Security Analysis: Two Examples 189

6.4 System Complexity Drivers and Security 203

6.5 Deep Technical Problem Complexity 215

6.6 Summary 217

Chapter 7: Governance, and Managing for More Secure Software 221

7.1 Introduction 221

7.2 Governance and Security 223

7.3 Adopting an Enterprise Software Security Framework 226

7.4 How Much Security Is Enough? 236

7.5 Security and Project Management 244

7.6 Maturity of Practice 259

7.7 Summary 266

Chapter 8: Getting Started 267

8.1 Where to Begin 269

8.2 In Closing 281

Product Details

ISBN-13:	9780321509178
Publisher:	Pearson Education
Publication date:	05/01/2008
Series:	SEI Series in Software Engineering
Edition description:	New Edition
Pages:	368
Product dimensions:	7.00(w) x 9.20(h) x 0.70(d)

About the Author

Julia H. Allen is a senior member of the technical staff within the CERT Program at the Software Engineering Institute (SEI), a unit of Carnegie Mellon University in Pittsburgh, PA. In addition to her work in software security and assurance, Allen is engaged in developing and transitioning executive outreach programs in enterprise security and governance. She is the author of The CERT Guide to System and Network Security Practices (Addison-Wesley, 2001), Governing for Enterprise Security (CMU/SEI, 2005), and the CERT Podcast Series: Security for Business Leaders (2006/2007).

Sean Barnum is a Principal Consultant at Cigital and is technical lead for their federal services practice. He has more than twenty years of experience in the software industry in the areas of development, software quality assurance, quality management, process architecture and improvement, knowledge management, and security. He is a frequent contributor and speaker for regional and national software security and software quality publications, conferences, and events. He is very active in the software assurance community and is involved in numerous knowledge standards-defining efforts, including the Common Weakness Enumeration (CWE), the Common Attack Pattern Enumeration and Classification (CAPEC), and other elements of the Software Assurance Programs of the Department of Homeland Security and the Department of Defense. He is also the lead technical subject matter expert for the Air Force Application Software Assurance Center of Excellence.

Robert J. Ellison, Ph.D., is a member of the Survivable Systems Engineering Team within the CERT Program at the Software Engineering Institute and, in that capacity, has served in a number of technical and management roles. He was a project leader for the evaluation of software engineering development environments and associated software development tools. He was also a member of the Carnegie Mellon University team that wrote the proposal for the SEI; he joined the new FFRDC in 1985 as a founding member. Ellison regularly participates in the evaluation of software architectures and contributes from the perspective of security and reliability measures.

Gary McGraw, Ph.D., is the CTO of Cigital, Inc., a software security and quality consulting firm with headquarters in the Washington, D.C., area. He is a globally recognized authority on software security and the author of six best selling books on this topic. The latest is Exploiting Online Games (Addison-Wesley, 2008). His other titles include Java Security, Building Secure Software, Exploiting Software, and Software Security; and he is editor of the Addison-Wesley Software Security series. McGraw has also written more than ninety peer-reviewed scientific publications, authors a monthly security column for darkreading.com, and is frequently quoted in the press. Besides serving as a strategic counselor for top business and IT executives, Gary is on the Advisory Boards of Fortify Software and Raven White. He serves on the Dean’s Advisory Council for the School of Informatics at Indiana University. Gary is an IEEE Computer Society Board of Governors member and produces the monthly Silver Bullet Security Podcast for IEEE Security & Privacy magazine.

Nancy R. Mead, Ph.D., is a senior member of the technical staff in the Survivable Systems Engineering Group, which is part of the CERT Program at the Software Engineering Institute. Mead is also a faculty member in the Master of Software Engineering and Master of Information Systems Management programs at Carnegie Mellon University. She has more than one hundred publications and invited presentations. She is a fellow of the Institute of Electrical and Electronic Engineers, Inc. (IEEE) and the IEEE Computer Society and is also a member of the Association for Computing Machinery (ACM).

Table of Contents

Foreword xi

Preface xiii

About the Authors xxiii

Chapter 1: Why Is Security a Software Issue? 1

1.1 Introduction 1

1.2 The Problem 2

1.3 Software Assurance and Software Security 6

1.4 Threats to Software Security 9

1.5 Sources of Software Insecurity 11

1.6 The Benefits of Detecting Software Security Defects Early 13

1.7 Managing Secure Software Development 18

1.8 Summary 23

Chapter 2: What Makes Software Secure? 25

2.1 Introduction 25

2.2 Defining Properties of Secure Software 26

2.3 How to Influence the Security Properties of Software 36

2.4 How to Assert and Specify Desired Security Properties 61

2.5 Summary 71

Chapter 3: Requirements Engineering for Secure Software 73

3.1 Introduction 73

3.2 Misuse and Abuse Cases 78

3.3 The SQUARE Process Model 84

3.4 SQUARE Sample Outputs 91

3.5 Requirements Elicitation 99

3.6 Requirements Prioritization 106

3.7 Summary 112

Chapter 4: Secure Software Architecture and Design 115

4.1 Introduction 115

4.2 Software Security Practices for Architecture and Design: Architectural Risk Analysis 119

4.3 Software Security Knowledge for Architecture and Design: Security Principles, Security Guidelines, and Attack Patterns 137

4.4 Summary 148

Chapter 5: Considerations for Secure Coding and Testing 151

5.1 Introduction 151

5.2 Code Analysis 152

5.3 Coding Practices 160

5.4 Software Security Testing 163

5.5 Security Testing Considerations Throughout the SDLC 173

5.6 Summary 180

Chapter 6: Security and Complexity: System Assembly Challenges 183

6.1 Introduction 183

6.2 Security Failures 186

6.3 Functional and Attacker Perspectives for Security Analysis: Two Examples 189

6.4 System Complexity Drivers and Security 203

6.5 Deep Technical Problem Complexity 215

6.6 Summary 217

Chapter 7: Governance, and Managing for More Secure Software 221

7.1 Introduction 221

7.2 Governance and Security 223

7.3 Adopting an Enterprise Software Security Framework 226

7.4 How Much Security Is Enough? 236

7.5 Security and Project Management 244

7.6 Maturity of Practice 259

7.7 Summary 266

Chapter 8: Getting Started 267

8.1 Where to Begin 269

8.2 In Closing 281

Glossary 283

References 291

Build Security In Web Site References 311

Index 317

Preface

The Problem Addressed by This Book

Software is ubiquitous. Many of the products, services, and processes that organizations use and offer are highly dependent on software to handle the sensitive and high-value data on which people’s privacy, livelihoods, and very lives depend. For instance, national security—and by extension citizens’ personal safety—relies on increasingly complex, interconnected, software-intensive information systems that, in many cases, use the Internet or Internet-exposed private networks as their means for communication and transporting data.

This ubiquitous dependence on information technology makes software security a key element of business continuity, disaster recovery, incident response, and national security. Software vulnerabilities can jeopardize intellectual property, consumer trust, business operations and services, and a broad spectrum of critical applications and infrastructures, including everything from process control systems to commercial application products.

The integrity of critical digital assets (systems, networks, applications, and information) depends on the reliability and security of the software that enables and controls those assets. However, business leaders and informed consumers have growing concerns about the scarcity of practitioners with requisite competencies to address software security Carey 2006. Specifically, they have doubts about suppliers’ capabilities to build and deliver secure software that they can use with confidence and without fear of compromise. Application software is the primary gateway to sensitive information. According to a Deloitte survey of 169 major global financial institutions, titled 2007 Global Security Survey: The Shifting Security Paradigm Deloitte 2007, current application software countermeasures are no longer adequate. In the survey, Gartner identifies application security as the number one issue for chief information officers (CIOs).

The absence of security discipline in today’s software development practices often produces software with exploitable weaknesses. Security-enhanced processes and practices—and the skilled people to manage them and perform them—are required to build software that can be trusted to operate more securely than software being used today.

That said, there is an economic counter-argument, or at least the perception of one: Some business leaders and project managers believe that developing secure software slows the software development process and adds to the cost while not offering any apparent advantage. In many cases, when the decision reduces to “ship now” or “be secure and ship later,” “ship now” is almost always the choice made by those who control the money but have no idea of the risks. The opposite side of this argument, including how software security can potentially reduce cost and schedule, is discussed in Chapter 1 (Section 1.6, “The Benefits of Detecting Software Security Defects Early”) and Chapter 7 (Section 7.5.3, in the “Knowledge and Expertise” subsection discussing Microsoft’s experience with its Security Development Lifecycle) in this book.

Software’s Vulnerability to Attack

The number of threats specifically targeting software is increasing, and the majority of network- and system-level attacks now exploit vulnerabilities in application-level software. According to CERT analysts at Carnegie Mellon University, ¹ most successful attacks result from targeting and exploiting known, unpatched software vulnerabilities and insecure software configurations, a significant number of which are introduced during software design and development.

These conditions contribute to the increased risks associated with software-enabled capabilities and exacerbate the threat of attack. Given this atmosphere of uncertainty, a broad range of stakeholders need justifiable confidence that the software that enables their core business operations can be trusted to perform as intended.

Why We Wrote This Book: Its Purpose, Goals, and Scope The Challenge of Software Security Engineering

Software security engineering entails using practices, processes, tools, and techniques to address security issues in every phase of the software development life cycle (SDLC). Software that is developed with security in mind is typically more resistant to both intentional attack and unintentional failures. One view of secure software is software that is engineered “so that it continues to function correctly under malicious attack” McGraw 2006 and is able to recognize, resist, tolerate, and recover from events that intentionally threaten its dependability. Broader views that can overlap with software security (for example, software safety, reliability, and fault tolerance) include the notion of proper functioning in the face of unintentional failures or accidents and inadvertent misuse and abuse, as well as reducing software defects and weaknesses to the greatest extent possible regardless of their cause. This book addresses the narrower view.

The goal of software security engineering is to build better, defect-free software. Software-intensive systems that are constructed using more securely developed software are better able to do the following:

• Continue operating correctly in the presence of most attacks by either resisting the exploitation of weaknesses in the software by attackers or tolerating the failures that result from such exploits
• Limit the damage resulting from any failures caused by attack-triggered faults that the software was unable to resist or tolerate and recover as quickly as possible from those failures

No single practice offers a universal “silver bullet” for software security. With this caveat in mind, Software Security Engineering: A Guide for Project Managers provides software project managers with sound practices that they can evaluate and selectively adopt to help reshape their own development practices. The objective is to increase the security and dependability of the software produced by these practices, both during its development and during its operation.

What Readers Can Expect

Readers will increase their awareness and understanding of the security issues in the design and development of software. The book’s content will help readers recognize how software development practices can either contribute to or detract from the security of software.

The book (and material referenced on the Build Security In Web site described later in this preface) will enable readers to identify and compare potential new practices that can be adapted to augment a project’s current software development practices, thereby greatly increasing the likelihood of producing more secure software and meeting specified security requirements. As one example, assurance cases can be used to assert and specify desired security properties, including the extent to which security practices have been successful in satisfying security requirements. Assurance cases are discussed in Chapter 2 (Section 2.4, “How to Assert and Specify Desired Security Properties”).

Software developed and assembled using the practices described in this book should contain significantly fewer exploitable weaknesses. Such software can then be relied on to more capably resist or tolerate and recover from attacks and, therefore, to function more securely in an operational environment. Project managers responsible for ensuring that software and systems adequately address their security requirements throughout the SDLC should review, select, and tailor guidance from this book, the Build Security In Web site, and the sources cited throughout this book as part of their normal project management activities.

The five key take-away messages for readers of this book are as follows:

1. Software security is about more than eliminating vulnerabilities and conducting penetration tests. Project managers need to take a systematic approach to incorporate the sound practices discussed in this book into their development processes (all chapters).
2. Network security mechanisms and IT infrastructure security services do not sufficiently protect application software from security risks (Chapters 1 and 2).
3. Software security initiatives should follow a risk management approach to identify priorities and determine what is “good enough,” while understanding that software security risks will inevitably change throughout the SDLC (Chapters 1, 4, and 7).
4. Developing secure software depends on understanding the operational context in which it will be used (Chapter 6).
5. Project managers and software engineers need to learn to think like an attacker to address the range of things that software should not do and identify how software can better resist, tolerate, and recover when under attack (Chapters 2, 3, 4, and 5).

Who Should Read This Book

Software Security Engineering: A Guide for Project Managers is primarily intended for project managers who are responsible for software development and the development of software-intensive systems. Lead requirements analysts, experienced software and security architects and designers, system integrators, and their managers should also find this book useful. It provides guidance for those involved in the management of secure, software-intensive systems, either developed from scratch or through the assembly, integration, and evolution of acquired or reused software.

This book will help readers understand the security issues associated with the engineering of software and should help them identify practices that can be used to manage and develop software that is better able to withstand the threats to which it is increasingly subjected. It presumes that readers are familiar with good general systems and software engineering management methods, practices, and technologies.

How This Book Is Organized

This book is organized into two introductory chapters, four technical chapters, a chapter that describes governance and management considerations, and a concluding chapter on how to get started.

Chapter 1, Why Is Security a Software Issue?, identifies threats that target most software and the shortcomings of the software development process that can render software vulnerable to those threats. It describes the benefits of detecting software security defects early in the SDLC, including the current state of the practice for making the business case for software security. It closes by introducing some pragmatic solutions that are further elaborated in the chapters that follow.

Chapter 2, What Makes Software Secure?, examines the core and influential properties of software that make it secure and the defensive and attacker perspectives in addressing those properties, and discusses how desirable traits of software can contribute to its security. The chapter introduces and defines the key resources of attack patterns and assurance cases and explains how to use them throughout the SDLC.

Chapter 3, Requirements Engineering for Secure Software, describes practices for security requirements engineering, including processes that are specific to eliciting, specifying, analyzing, and validating security requirements. This chapter also explores the key practice of misuse/abuse cases.

Chapter 4, Secure Software Architecture and Design, presents the practice of architectural and risk analysis for reviewing, assessing, and validating the specification, architecture, and design of a software system with respect to software security, and reliability.

Chapter 5, Considerations for Secure Coding and Testing, summarizes key practices for performing code analysis to uncover errors in and improve the quality of source code, as well as practices for security testing, white-box testing, black-box testing, and penetration testing. Along the way, this chapter references recently published works on secure coding and testing for further details.

Chapter 6, Security and Complexity: System Assembly Challenges, describes the challenges and practices inherent in the design, assembly, integration, and evolution of trustworthy systems and systems of systems. It provides guidelines for project managers to consider, recognizing that most new or updated software components are typically integrated into an existing operational environment.

Chapter 7, Governance, and Managing for More Secure Software, describes how to motivate business leaders to treat software security as a governance and management concern. It includes actionable practices for risk management and project management and for establishing an enterprise security framework.

Chapter 8, Getting Started, summarizes all of the recommended practices discussed in the book and provides several aids for determining which practices are most relevant and for whom, and where to start. The book closes with a comprehensive bibliography and glossary.

Notes to the Reader Navigating the Book’s Content

As an aid to the reader, we have added descriptive icons that mark the book’s sections and key practices in two practical ways:

• Identifying the content’s relative “maturity of practice”:

• L1: The content provides guidance for how to think about a topic for which there is no proven or widely accepted approach. The intent of the description is to raise awareness and aid the reader in thinking about the problem and candidate solutions. The content may also describe promising research results that may have been demonstrated in a constrained setting.
• L2: The content describes practices that are in early (pilot) use and are demonstrating some successful results.
• L3: The content describes practices that are in limited use in industry or government organizations, perhaps for a particular market sector.
• L4: The content describes practices that have been successfully deployed and are in widespread use. Readers can start using these practices today with confidence. Experience reports and case studies are typically available.

• Identifying the designated audiences for which each chapter section or practice is most relevant:

• E: Executive and senior managers
• M: Project and mid-level managers
• L: Technical leaders, engineering managers, first-line managers, and supervisors

As the audience icons in the chapters show, we urge executive and senior managers to read all of Chapters 1 and 8, plus the following sections in other chapters: 2.1, 2.2, 2.5, 3.1, 3.7, 4.1, 5.1, 5.6, 6.1, 6.6, 7.1, 7.3, 7.4, 7.6, and 7.7.

Project and mid-level managers should be sure to read all of Chapters 1, 2, 4, 5, 6, 7, and 8, plus these sections in Chapter 3: 3.1, 3.3, and 3.7.

Technical leaders, engineering managers, first-line managers, and supervisors will find useful information and guidance throughout the entire book.

Build Security In: A Key Resource

Since 2004, the U.S. Department of Homeland Security Software Assurance Program has sponsored development of the Build Security In (BSI) Web site (https://buildsecurityin.us-cert.gov/), which was one of the significant resources used in writing this book. BSI content is based on the principle that software security is fundamentally a software engineering problem and must be managed in a systematic way throughout the SDLC.

BSI contains and links to a broad range of information about sound practices, tools, guidelines, rules, principles, and other knowledge to help project managers deploy software security practices and build secure and reliable software. Contributing authors to this book and the articles appearing on the BSI Web site include senior staff from the Carnegie Mellon Software Engineering Institute (SEI) and Cigital, Inc., as well as other experienced software and security professionals.

Several sections in the book were originally published as articles in IEEE Security & Privacy magazine and are reprinted here with the permission of IEEE Computer Society Press. Where an article occurs in the book, a statement such as the following appears in a footnote:

This section was originally published as an article in IEEE Security & Privacy citation. It is reprinted here with permission from the publisher.

These articles are also available on the BSI Web site. Articles on BSI are referenced throughout this book. Readers can consult BSI for additional details, book errata, and ongoing research results.

Start the Journey

A number of excellent books address secure systems and software engineering. Software Security Engineering: A Guide for Project Managers offers an engineering perspective that has been sorely needed in the software security community. It puts the entire SDLC in the context of an integrated set of sound software security engineering practices.

As part of its comprehensive coverage, this book captures both standard and emerging software security practices and explains why they are needed to develop more security-responsive and robust systems. The book is packed with reasons for taking action early and revisiting these actions frequently throughout the SDLC.

This is not a book for the faint of heart or the neophyte software project manager who is confronting software security for the first time. Readers need to understand the SDLC and the processes in use within their organizations to comprehend the implications of the various techniques presented and to choose among the recommended practices to determine the best fit for any given project.

Other books are available that discuss each phase of secure software engineering. Few, however, cover all of the SDLC phases in as concise and usable a format as we have attempted to do here. Enjoy the journey!

Notes:
Selected content in this preface is summarized and excerpted from Security in the Software Lifecycle: Making Software Development Processes—and Software Produced by Them—More Secure Goertzel 2006.
1. CERT (www.cert.org) is registered in the U.S. Patent and Trademark Office by Carnegie MellonUniversity.

References:
Carey 2006 Carey, Allan. “2006 Global Information Security Workforce Study.” Framingham, MA: IDC, 2006. https://www.isc2.org/download/workforcestudy06.pdf
Deloitte 2007 Deloitte Touche Tohmatsu. 2007 Global Security Survey: The Shifting Security Paradigm. September 2007. http://www.deloitte.com/
Goertzel 2006 Goertzel, Karen Mercedes, Winograd, Theodore, McKinley, Holly Lynne, & Holley, Patrick. Security in the Software Lifecycle: Making Software Development Processes—and Software Produced by Them—More Secure, Draft version 1.2. U.S. Department of Homeland Security, August 2006.
McGraw 2006 McGraw, Gary. Software Security: Building Security In. Boston, MA: Addison-Wesley, 2006.