Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software

Download 1.28 Mb.
Date conversion09.01.2018
Size1.28 Mb.
  1   2   3   4   5   6   7   8   9   ...   55

Software Assurance Series

Software Assurance

A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software

DRAFT Version 1.0

July 7, 2006

[July 7, 2006 NOTE – Page to be updated]

Version v. 1.0.227 07 July 2006


Please Ensure Proper Acknowledgement

When referring to, quoting, or excerpting from this document please always ensure proper acknowledgement is given.

Citation: Samuel T. Redwine, Jr. (Editor). Software Assurance: A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software Version 1.0. US Department of Homeland Security, May 2006.

How to Make Contact, Find out More, and Contribute

Through a jointly sponsored working group, Software Assurance Workforce Education and Training, the Department of Homeland Security (DHS) Software Assurance Program is seeking additional input and participation in further developing this Secure Software Assurance Common Body of Knowledge document. Representatives from government, academia, and the private industry have identified key information needed to educate and train on the development, sustainment, and acquisition of secure software. This document is offered for informative use; it is not intended as a policy or standard.

If you would like to interact regarding this document, participate in the Workforce Education and Training Working Group, or find out more information about the security of software and the DHS efforts to improve it; visit the “Build Security In” website at



Use of any trademarks in this guide is not intended in any way to infringe on the rights of the trademark holder.

References in this document to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, do not necessarily constitute or imply its endorsement, recommendation, or favoring by any of the parties involved in or related to this document. No warranty is made that use of the guidance in this document or on any site, which is the source of this document, will result in software that is secure or more secure. Code examples are for illustrative purposes and are not intended to be used as is or without undergoing analysis.

Request for Reader: Please provide advance comments if additional comments are identified. Comments to be removed for publishing but will be used, as applicable, in outreach material.

Security is of growing importance as computers become ever more pervasive. Security, and the development of secure software and systems, has moved from being a specialist or niche area, to being an important aspect of the work of many software developers and project managers. However, the “body of knowledge” for secure computing is large and diverse, and has not hitherto been clearly identified or collected into a coherent framework. Whilst there are inevitably areas of this “body of knowledge” which can be improved, Sam Redwine has done the community a great service in compiling the first extensive document covering most of the key issues in developing and assuring secure software. It is a “tour de force” and I am delighted to commend it to anyone with a serious concern for computer security.”

John A. McDermid, FREng
Professor of Software Engineering and leader of the High Integrity Systems Engineering Group
University of York

This is a document needed in the Software Engineering community - both academic and industrial… After having seen a draft of the CBOK document, we elected to move ahead with a software assurance class … We appreciate the great deal of effort you [Sam Redwine] and others have put into this document … and we compliment you for your efforts.”

Rayford Vaughn
Billie J. Ball Professor of Computer Science
Engineering Director, Center for Computer Security Research
Mississippi State University

I pay tribute to its developers for creating this badly needed and unique resource. The Object Management Group’s Software Assurance effort is already benefiting from it, and now others have the opportunity as well.”

Djenana Campara
CTO, Klocwork

Co-Chair, OMG Software Assurance Special Interest Group

Sam Redwine did a masterful job putting this together. He is storing up treasures in ‘bit heaven’. Everyone interested in software security should say THANK YOU!”

Mary Ann Davidson
Chief Security Officer
Oracle Corporation

The SwA CBK makes a valuable contribution to solving the many problems of producing and deploying trustworthy software. In particular, I am pleased to see the inclusion of mathematically-based, constructive techniques alongside more pragmatic approaches. As the document itself notes: showing that a system is trustworthy is often much harder than making it trustworthy in the first place… greatly to be applauded.”

Peter Amey
CTO (Software Engineering)

Praxis High Integrity Systems

I used the [draft] Guide with considerable success within an advanced level III course. The students found it extremely valuable.”

Carl Clavadetscher
Professor of Systems Management
National Defense University

The opportunities for miscreant and malicious forces to compromise … the information age with corrupted software has never been greater. It will take persistent, concerted, and heroic efforts to move our entire software paradigm … onto the path of quality, robustness, usability, …. This Secure Software Assurance effort, an effort whose time is well overdue, is a beginning of that move … it must be commended.

Blaine Burnham
Senior Research Fellow
University of Nebraska Omaha

Critical questions from the customer to the developer are: ‘How do you know that the software being design and built will meet the specified security requirements?’ and, ‘How can you assure the stakeholders that the software being built will meet the secure software assurance requirements in an operational environment?’

This document hits the mark by providing evaluators, standards developers, and practitioners (principally developers and testers) with source materials on a comprehensive summation of the topics, facts, principles, and practices of software security and its assurance.”

Kenneth E. Nidiffer
Systems and Software Consortium (SSCI)

Commenting on draft version 0.9: “The DHS Software Assurance Program document Secure Software Assurance - A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software (Draft, v0.9) provides an excellent overview of the current body of knowledge available for the development of software worthy of trust in the face of threat. The document clearly expresses the need to stop forgetting what has already been discovered and provides an outstanding compilation of existing computing security work upon which to build future endeavors. The document [version 0.9] is also clearly an early draft that will benefit from the public review that is an intended part of the document development. Finally, the document has great potential to support a substantive change in the capability of software developers when incorporated into a broader strategy for implementing such change”.

Gary Stoneburner
Johns Hopkins University Applied Physics Laboratory
Formerly the technical advisor to the NIST FISMA implementation project and the NIST technical representative to the Common Criteria Project

Authorship and Acknowledgements

[July 7, 2006 Note: Section to be updated]

The Department of Defense (DoD) and Department of Homeland Security (DHS) Software Assurance efforts encompass software safety, security, reliability, and dependability; yet initially they are concentrating on achieving and assuring security properties and functionality. The Software Assurance (SwA) Workforce Education and Training Working Group is composed of government, industry, and academic members. This Working Group produced this document as its first step towards achieving adequate US education and training on software assurance. It identifies the additional body of knowledge necessary to develop, sustain, and acquire secure software beyond that normally required to produce and assure software where safety and security are not concerns. The knowledge areas identified and their related references provide a foundation for producing education and training curricula and products as well as being useful to standards developers, evaluators and testers, and others wishing to be knowledgeable about what is involved in the engineering of software that is secure.1

This document was developed by:

Samuel T. Redwine, Jr.

Samuel T. Redwine, Jr.
Rusty O. Baldwin
Mary L. Polydys
Daniel P. Shoemaker
Jeffrey A. Ingalsbe

Larry D. Wagoner

Additional contributors included: Martin Croxford of Praxis High Integrity Systems Ltd; John McDermid, University of York; Jim Moore, MITRE; Mary Ann Davidson, Oracle; and the Ford Motor Company whose staff helped in the production of the section on Sustainment particularly its reference list.

The editor and authors want to thank their co-authors for mutual help, the Working Group members for the review comments received and the helpful issue discussions that occurred, and external reviewers who contributed their valuable time to improve this guide. In part, James Madison University and its Institute for Infrastructure and Information Assurance supported Sam Redwine’s work.

Reviews of all or parts of drafts of this document were provided by:

Mark R. Blackburn, Systems and Software Consortium, Inc.

Florian P. Buchholz, James Madison University
J. Katharine Burton, Institute for Defense Analyses
Mary Ann Davidson, Oracle
Robert Dupuis, Université du Québec à Montréal
Christopher Fox, James Madison University
Frank Herman, Fraunhofer Center for Experimental Software Engineering, Maryland
George Huber, SRI
David Jackson, QinetiQ
David Ladd, Microsoft
Seok-Won Lee, University of North Carolina Charlotte
Glen Logan, OUSD(AT&L)
Vic Maconachy, National Security Agency
Nancy Mead, Software Engineering Institute, Carnegie Mellon
James W. Moore, The MITRE Corporation
Sarah Nash, Institute for Defense Analyses
Ken Nidiffer, Systems and Software Consortium, Inc.
Ioana Rus, Fraunhofer Center for Experimental Software Engineering, Maryland
Joseph M. Saur, Georgia Tech Research Institute, Joint Systems Integration Command
Gary R. Stoneburner, Johns Hopkins University Applied Physics Laboratory
John Viega, Secure Software
Larry Wagoner, National Security Agency
James Walden, Northern Kentucky University
David A. Wheeler, Institute for Defense Analyses

Stan Wisseman, Booz Allen Hamilton

Special thanks go to:

Joe Jarzombek, Director of Software Assurance, Department of Homeland Security - National Cyber Security Division, without whose leadership and support this report would not exist

Mitchell Komaroff, Office of Assistant Secretary of Defense (Networks and Information Integration), for his Department of Defense-related efforts

Joseph Saur championed and managed the early efforts to produce the Acquisition portion

Jim Moore of The Mitre Corporation was particularly helpful. He personally discussed many aspects of the document, provided detailed reviews and links into the standards community, and made extensive interaction time available with the Process and Practices Working Group.

David Ladd of Microsoft attended all the early meetings and made his extensive expertise and advice freely available inside and outside the meetings. The WG’s plans for future enlargement of participation owe much to his championing of this need.

Robert Dupuis identified many areas where the text presumed more knowledge than exists in the Guide to the Software Engineering Body of Knowledge in which he has been instrumental (any remaining difficulties are solely the responsibility of the authors)

David Wheeler for pointing out convincingly that the need to be concerned about security is now the “normal” case for software

For the Sustainment portion, Jeff Voas, Shareli Zadeli, Antonio Drommi provided comments and/or useful participation

Nancy Mead, Robert Ellison, and others at the Software Engineering Institute, and Gary McGraw and others at Cigital who shared their efforts in this area

John McDermid of the University of York not only contributed quoted text but generously provided an especially useful discussion on a hot afternoon/evening in Washington, as well as pointing to a number of useful references

Chuck Howell of The MITRE Corporation spent an evening providing the benefit of his experience with assurance cases including discussing the workshop he Chair on the subject.

Mark Vanfleet of NSA for useful discussion and identification of experts

Gary Stoneburner of John Hopkins University provided stimulating and useful discussion and comments

The students in CS480 Secure Software Engineering at James Madison University who helped identify places where the text could be improved

Lisa Enders, Ginna Baker, Kelly Rote, and Christine Jones, James Madison University student assistants who toiled diligently on the many unglamorous tasks that needed to be done

The Working Group members were:

Lawrence Baker, Defense Acquisition University

Rusty O. Baldwin, Air Force Institute of Technology
Paul E. Black, National Instituted of Standards and Technology (NIST)
Blaine Burnham, University of Nebraska at Omaha
J. Katharine Burton, Institute for Defense Analyses
Djenana Campara, Klocwork Inc.
Mary Carroll, Information Resources Management College at National Defense University
Martin Croxford, Praxis High Integrity Systems Ltd.
Mary Ann Davidson, Oracle
Antonio Drommi, University of Detroit Mercy
Robert Dupuis, Université du Québec à Montréal
Frank Herman, Fraunhofer Center for Experimental Software Engineering, Maryland
Jeffrey A. Ingalsbe, Ford Motor Company
Arthur King, IBM Business Consulting Services supporting OASD(NII) DIAP
Michael Kass, NIST
Michael Koo, NIST
David Ladd, Microsoft Research
Barbara Laswell, Software Engineering Institute, Carnegie Mellon
Seok-Won Lee, University of North Carolina Charlotte
Tom McGibbon, ITT Industries
James W. Moore, The MITRE Corporation
Sarah Nash, Institute for Defense Analyses
Mary Linda Polydys, Information Resources Management College at National Defense University
Samuel T. Redwine, Jr. James Madison University
Joseph M. Saur, Georgia Tech Research Institute, Joint Systems Integration Command
Edward A. Schneider, Institute for Defense Analyses
Dan Shoemaker, University of Detroit Mercy
Frank Stomp, Wayne State University
Jeffrey Voas, Science Applications International Corporation
Larry Wagoner, National Security Agency
David A. Wheeler, Institute for Defense Analyses

Sherali Zeadally, Wayne State University

The IEEE International Symposium on Secure Software Engineering and the Software Assurance Forum provide opportunities for additional information in this area. The Workshop on Secure Software Engineering Education and Training is specifically on the topic.

The Working Group’s life extends beyond the production of this guide, and its goals remain the same, to help create a workforce capable of developing, sustaining, assuring, and acquiring (more) secure software – but its specific activities may vary. The Working Group welcomes participation in its ongoing activities.2

Editor’s Preface

[July 7, 2006 Note: Section to be updated]


In June 2005, I took on the task of editing a document intended to provide educators, trainers, and others possessing knowledge of software but not of security a companion to guide them across the surface of the discipline of secure software engineering and point out locations where further knowledge can be obtained by digging into the identified references. I was roughly aware of the size of the task, but I did not appreciate the difficulties that would occur in bringing adequate resources to bear. A few people worked quite hard with almost no recompense to first produce a draft, distributed in early October 2005, and to progress through a series of iterations to reach this version. I hope this guide inspires and aids the development of products and services from academia, industry, and government by helping people identify relevant items in the existing body of knowledge.

Along the way, a number of individuals and organizations gave comments both large and small on the many interim drafts providing feedback that I and the other authors greatly appreciated – though we were always eager for more. Comments were universally positive in their effects, and commenters should not be blamed for any remaining shortcomings. Interest and involvement came not just from community-minded individuals within the US, but from some in Europe and Canada as well. In the end, this document is the result of those individuals and organizations willing to put in their own resources and step up to do a needed task, and I greatly appreciate them all. In the future, guide’s evolution benefits from involvement of even more of the community including feedback from users.

The guiding principle behind selecting the guide’s contents and organization was to have the text straightforwardly supply the background and contextual software-specific security or assurance knowledge that persons already possessing good software engineering knowledge need to be familiar enough with to identify which references might be of interest – what a reference is about. While we did not attempt to produce a textbook, and this guide is not one, some may choose to use its content as a high-level introduction to the subject matter. However, in its primary role, educators and trainers as well as others will use this document to guide them to the references containing the more detailed software-specific security knowledge relevant to their work. Therefore, its design allows users – after reading the material everyone needs to be acquainted with that is laid out in the first four sections – to move directly to the section(s) of interest. Any related required knowledge is then cross-referenced. The guide also, however, reads properly front to back with prerequisite knowledge being introduced before it is required.

The primary audiences for this guide are educators and trainers to help them identify both appropriate curricular content and references that detail it. Other audiences include evaluators and testers, acquisition personnel, and standards developers for whom it can help provide a better appreciation of the breadth of subject matter and issues involved. Given the unanticipated accessibility of this guide, studious practitioners could use it to obtain overviews or to guide their learning.

This preface provides a history of the development this guide to the secure software engineering common body of knowledge and guidance on the paths within the document that readers with different interests may take. Those without interest in this history can proceed directly to “How to Read this Document“, or to the Introduction.

Some History

In 2003, the US Department of Defense (DoD) launched a Software Assurance Initiative led by Joe Jarzombek,3 and this was joined in 2004 by the Department of Homeland Security (DHS). In March 2005, Mr. Jarzombek moved to become Director for Software Assurance, National Cyber Security Division within DHS and retains his leadership role in the collaborative interagency Software Assurance efforts including overseeing the development of this Secure Software Assurance (SwA) Common Body of Knowledge (CBK).

The DoD and DHS Software Assurance initiatives have submitted internal, interim reports and held jointly sponsored Software Assurance Forums and a number of individual working group (WG) meetings. One of the working groups focuses on education and training, and includes the members from government, industry, and academia who collaborated to produce this guide. In hopes of soliciting further participation, Joe Jarzombek and others also made a number of appearances at professional events to publicize the efforts and the problems they are addressing.

Driven by awareness of the rampant worldwide explosion in exploitation of software vulnerabilities, demand is growing for low-defect, secure software, in both the defense and commercial sectors. Current, commonplace software specification, design, implementation, and testing practices provide users with software containing numerous defects and security vulnerabilities.4 Government and industry need processes that effectively and efficiently acquire, develop, and sustain secure software; means to justify confidence in these processes and their products; and practitioners that are motivated, disciplined, and proficient in their execution.

Currently, other Working Groups are concentrating on other aspects of achieving and assuring security properties and functionality5 including standards, measurement, and tools. The Workforce Education and Training Working Group is addressing the issues related to achieving adequate US education and training on engineering of secure software, including skill shortages within government and industry, and curriculum needs within universities, colleges, and trade schools.6

The WG asked the following questions:

  1. What are the engineering activities or aspects of activities that are relevant to achieving secure software?

  2. What knowledge is needed to perform these activities or aspects?

The early meetings addressing these questions were sometimes uneven and involved brainstorming sessions producing lists of terms and topics – sometimes without shared definitions or understanding. Starting any effort involving a number of people of disparate backgrounds and skills can be hard, and, luckily, the document managed to benefit from these early efforts and progressed well beyond any potential ill effects on its quality.

Deciding what knowledge to presume of the readers of this guide took several twists and turns. Initially, the subgroup addressing software development took the Guide to the Software Engineering Body of Knowledge (SWEBOK7) [Abran 2004] as a starting point for establishing its presumption of knowledge already identified. The WG knew, however, that the intended readership did not necessarily know this much, and it always tried not to presume more of readers than could be reasonably expected. The WG’s and this SwA CBK’s goal was to identify the “additional” knowledge needed for developing, sustaining, and acquiring secure software while recognizing that a clear boundary for what is “additional” does not always exist. For some knowledge elements, the difference is mainly in the extremely detailed knowledge or level of rigor required for secure software.

The subgroups on Acquisition and Supply and on Sustainment and Operations had even more difficult problems in finding existing descriptions as bases for their “presumed” bodies of knowledge. As partial answers, the acquisition subgroup used federal acquisition documents and sustainment used the Maintenance section of SWEBOK Guide and relevant standards.

Fortunately, the efforts to answer the question “What are the engineering activities or aspects of activities that are relevant to achieving secure software?” benefited from a number of prior efforts and products. Though the subject of this document is security for software, the techniques, concepts, and references derived from software safety practice are included because these have been found to provide a good basis for adaptation or extension to achieve software security objectives. The “prior knowledge” drawn upon in compiling this guide includes:

  • National Cyber Security Partnership Taskforce Report on Processes to Produce Secure Software [Redwine 2004]

  • Safety and Security Extensions for Integrated Capability Maturity Models [Ibrahim et al, 2004]

  • IEEE Software and Systems Engineering Standards Committee (S2ESC) collection of IEEE standards

  • ISO/IEC JTC1/SC7 WG9 Redefined its terms of reference to software and system assurance (part of Systems Engineering System Life Cycle Processes)

  • ISO/IEC 15026 to address management of risk and assurance of safety, security, & dependability within context of system and software life cycles [ISO 15026]

  • National Institute of Standards and Technology (NIST) FISMA Implementation Project

  • The Common Criteria for evaluating the security of software including the new version 3.0 issued in July 2005 [CC 2005]

  • The SafSec effort in the UK8 combining concern for safety and security [SafSec Introduction], [SafSec Standard], and [SafSec Guidance]

  • A variety of safety-related standards efforts as they address a number of issues shared by safety and security in which the safety community has useful, relevant experience

Members of the WG include editors and authors within several of these efforts. Even with these prior efforts, answering the question about relevant activities occupied much initial effort. The WG has also benefited from the work of other Software Assurance Working Groups such as the working group on Software Assurance Processes and Practices, whose activities are focused on issues relating to the production and assurance of secure software.

For development, the resulting lists needed to be consolidated into some set of categories to form the structure of this document. Among the candidate sets of categories were those from:

  • ISO/IEC 15288 – System Life Cycle Processes

  • ISO/IEC 12207 – Software Life Cycle Processes

  • IEEE Computer Society – Guide to the Software Engineering Body of Knowledge9

  • ISO harmonization proposal for ISO/IEC 15288 and ISO/IEC 12207

  • IEEE Std 15288-2004 – Adoption of ISO/IEC 15288:2002 System Life Cycle Processes

  • IEEE/EIA 12207.0-1966 – Industry Implementation of ISO/IEC 12207:1995

Table 1: Comparison with SWEBOK Guide


This Document

Threats and Hazards

Fundamental Concepts and Principles

Ethics, Law, and Governance

Software Requirements

Secure Software Requirements

Software Design

Secure Software Design

Software Construction

Secure Software Construction

Software Testing

Secure Software Verification, Validation and Evaluation

Software Quality

portions of Secure Software Engineering Management

Software Engineering Tools and Methods

Secure Software Tools and Methods

Software Engineering Process

Secure Software Processes

Software Engineering Management

Secure Software Engineering Management

Acquisition of Secure Software

Software Maintenance

Secure Software Sustainment

Software Configuration Management

portions of Secure Software Engineering Management

  1   2   3   4   5   6   7   8   9   ...   55

The database is protected by copyright © 2017
send message

    Main page