Abstract
All systems have vulnerabilities, either in the technology from which they are constructed or in the behaviors of the people who use them.
Introduction
The Build Security In Guidelines is a taxonomy of mid-level engineering concerns that were derived from the vulnerability database accumulated by the CERT® Coordination Center over its 15-year history. In general, these concerns are less abstract than the Build Security In Principles—which are intended to be enduring top-level concerns—and more abstract than the Build Security In Coding Rules—which are intended to be precise, specific implementation advice.
The Taxonomy
Assume that Human Behavior Will Introduce Vulnerabilities into Your System
Assume that Technology Will Contain Vulnerabilities
Design Configuration Subsystems Correctly and Distribute Safe Default Configurations
Carefully Study Other Systems Before Incorporating Them into Your System Through Delegation
If Emulation of Another System Is Necessary, Ensure that It Is as Correct and Complete as Possible
Validate All Input as Precisely as Possible
Use All Security Mechanisms Correctly
Do Not Allow Your System to Ever Use or Depend on Language Behaviors that Are "Undefined"
Description
In every phase of a system's development, under particular conditions, features added—or omitted—can introduce security vulnerabilities. To produce a safe and secure system, the competent, security-conscious engineer must
learn the meaning of software assurance and be knowledgeable in the practice of supporting techniques,
recognize the security implications of all functional requirements,
recognize the security implications of missing requirements,
recognize emergent behaviors in the system that have security implications,
recognize the implications of an evolving deployment environment on the system,
translate those implications into additional system requirements,
design features to meet those requirements,
recognize the security implications of the included and omitted features,
add, modify, or remove features accordingly,
recognize the security implications of the system's implementation,
correct any defects in the implementation,
understand how to test the system for compliance with security requirements, and
be able to use software assurance techniques to demonstrate the assurance attributes of the system.
A failure in any of these, and more, can leave the system with security vulnerabilities.
Copyright © Carnegie Mellon University 2005-2012.
This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu.
The Build Security In (BSI) portal is sponsored by the U.S. Department of Homeland Security (DHS), National Cyber Security Division. The Software Engineering Institute (SEI) develops and operates BSI. DHS funding supports the publishing of all site content.
NO WARRANTY
THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.