Ideally, by now we will have convinced you that software security is a topic worthy of your attention. As software and security professionals, we will never be able to get ahead of the game by addressing security solely as an operational issue. Attackers are creative, ingenious, and increasingly motivated by financial gain. They have been learning how to exploit software for several decades; the same is not true for software engineers and we need to change this. Given the extent to which our nations, our economies, our businesses, and our families rely on software to sustain and improve our quality of life, we must make significant progress in putting higher-quality and more secure software into production. The practices described in this book serve as an excellent starting point for this journey.
To aid you in getting started, this chapter summarizes all of the practices presented in the preceding chapters. Practices described in each chapter are summarized here in tabular form (Tables 8–1 through 8–6), listed in the order of which practice to tackle first, then second, then third, and so forth. The practice order is established either by an author’s assessment of which practice makes most sense to do first based on its serving as a prerequisite for or a useful precursor to subsequent practices or by listing first those practices that are most mature and in widespread use.
Table 8–1. Software Security Practices That Span the SDLC (Chapter 2)
Description | Maturity | Audience | Relevant for These Roles | |
|---|---|---|---|---|
Properties of secure software | Core and influential properties of software that enable the understanding and description of its security characteristics | L4 | E, M, L |
|
Attack patterns | Formalized capture of common methods of attacking software to serve as guides for improving software attack resistance and resilience | L3 | M, L |
|
Assurance cases | Structured mechanism for capturing, communicating, and validating desired or attained levels of software security assurance in terms of the properties of secure software | L2 | M, L |
|
For example, Table 8–2 lists “Establish a defined process for identifying and documenting security requirements” as the first practice. Without a defined process, all of the other requirements engineering practices are deployed out of context; the defined process serves as the foundation for their implementation. Once this is in place, the practice order is then determined based on its ability to produce the best results from the process. With respect to Table 8–4, the practice order is more obvious. Clearly, you cannot review source code until it is developed (by using secure coding practices!), and you cannot test that code until you understand the unique aspects of software security testing.
Table 8–2. Requirements Engineering Practices (Chapter 3)
Description | Maturity | Audience | Relevant for These Roles | |
|---|---|---|---|---|
Standard security requirements engineering process | Establish a defined process for identifying and documenting security requirements, such as SQUARE | L3 | E, M, L |
|
Security risk assessment | Perform a risk assessment aimed at security exposures, either as part of a project risk assessment or as a stand-alone activity | L3 for security; L4 for projects in general | M, L |
|
Threat identification | Use techniques such as misuse/abuse cases, threat modeling, attack patterns, or attack trees to identify security threats | L3 | L |
|
Conduct a security requirements elicitation activity to identify potential security requirements | L2 | L |
| |
Security requirements categorization and prioritization | Categorize and prioritize security requirements to separate true requirements from architectural recommendations and to optimize cost–benefit considerations | L2 | L |
|
Security requirements inspection | Inspect security requirements in conjunction with other requirements to ensure they are correct and complete | L2 for security; L4 for inspections in general | L |
|
Each chapter practice table identifies the designated “maturity level” for each practice as follows:
 | The practice serves as 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 assist you 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. |
 | The practice is in early pilot use and demonstrating some successful results. |
 | The practice is in limited use in industry or government organizations, perhaps for a particular market sector. |
 | The practice has been successfully deployed and is in widespread use. You can start using this practice today with confidence. Experience reports and case studies are typically available for it as well. |
The tables identify the relevant reader audiences called out in the chapters:
 | Executive and senior managers |
 | Project and mid-level managers |
 | Technical leaders, engineering managers, first-line managers, and supervisors |
They also identify other relevant roles that need to understand a practice and are typically involved in its deployment.
Each project manager needs to carefully consider the knowledge, skills, and competencies of his or her development team, the organizational culture’s tolerance (and attention span) for change, and the degree to which sponsoring executives have bought in (a prerequisite for sustaining any improvement initiative). In some cases, it may be best to start with coding and testing practices (Table 8–4) given that these are the most mature, have a fair level of automated support, and can demonstrate some early successes, thereby providing visible benefit to help software security efforts gain support and build momentum. By contrast, requirements engineering (Table 8–2) and architecture and design practices (Table 8–3) offer opportunities to address more substantive root cause issues early in the life cycle that, if left unaddressed, will show up in code and testing. Practice selection and tailoring are specific to each organization and project, being based on the objectives, constraints, and criticality of the software under development. Software criticality is based on the functionality it provides and the information it processes.
Table 8–3. Architecture and Design Practices (Chapter 4)
Brief Description | Maturity | Audience | Relevant for These Roles | |
|---|---|---|---|---|
Security principles | High-level perspectives/practices to provide prescriptive guidance for architecture and design | L3 | M, L |
|
Attack patterns | Formalized capture of common methods of attacking software to serve as guides for improving the attack resistance and resilience of the software architecture | L3 | M, L |
|
Architectural risk analysis | Perform a detailed risk assessment of the software architecture and design and its ability to securely support the requirements of the software | L3 | M, L |
|
Security guidelines | Technology-specific prescriptive guidance founded on demonstrated experience to guide integrating security concerns into architecture and design | L3 | M, L |
|
Table 8–4. Coding and Testing Practices (Chapter 5)
Brief Description | Maturity | Audience | Relevant for These Roles | |
|---|---|---|---|---|
Secure coding practices | Use sound and proven secure coding practices to aid in reducing software defects introduced during implementation | L4 | M, L |
|
Source code review for security vulnerabilities | Perform source code review using static code analysis tools, metric analysis, and manual review to minimize implementation-level security bugs | L4 | M, L |
|
Unique aspects of software security testing | Understand the differences between software security testing and traditional software testing, and plan how best to address these (including thinking like an attacker and emphasizing how to exercise what the software should not do) | L3/4 | M, L |
|
Functional test cases for security | Construct meaningful functional test cases (using a range of techniques) that demonstrate the software’s adherence to its functional requirements, including its security requirements (positive requirements) | L4 | M, L |
|
Develop risk-based test cases (using, for example, misuse/abuse cases, attack patterns, or threat modeling) that exercise common mistakes, suspected software weaknesses, and mitigations intended to reduce or eliminate risks to ensure they cannot be circumvented (negative requirements) | L3/4 | M, L |
| |
Test cases using a range of security test strategies | Use a complement of testing strategies including white-box testing (based on deep knowledge of the source code), black-box testing (focusing on the software’s externally visible behavior), and penetration testing (identifying and targeting specific vulnerabilities at the system level) | L4 | M, L |
|
Project managers and software engineers need to better understand what constitutes secure software and develop their skills to think like an attacker—and then apply this mindset throughout the SDLC. The practices listed in Table 8–1 get this ball rolling and are the best place to start in terms of awareness, training, and education. Alternatively, if you have access to experienced security analysts, adding a few of them to your development team can jump-start this effort.
With respect to the context within which software lives, it is essential to consider the practices, processes, and mitigations identified in Table 8–5 (and Chapter 6), because they inform the practice selection process and help set expectations as to what is realistically achievable given the current state of the practice.
Table 8–5. Security Analysis for System Complexity and Scale: Mitigations (Chapter 6)
Two of the key project management practices are (1) defining and deploying a risk management framework to help inform practice selection and determine where best to devote scarce resources and (2) identifying how best to integrate software security practices into the organization’s current software development life cycle. These and other governance and management practices are described in Table 8–6 and Chapter 7.
Table 8–6. Governance and Management Practices (Chapter 7)
Brief Description | Maturity | Audience | Relevant for These Roles | |
|---|---|---|---|---|
Risk-based definition of adequate security | Identify ways to determine what constitutes adequate security practice based on risk management, established levels of risk tolerance, and risk assessment | L4 for information security; L3 for software security | E, M, L |
|
Continuous risk management framework | Put a continuous, business-driven risk management framework in place and periodically assess for acceptable and unacceptable levels of risk throughout the SDLC | L4 | M, L |
|
Software security practices integrated with SDLC | Provide recommendations for inserting security practices into the SDLC as part of traditional project management activities, including the use of defined security touchpoints at each life-cycle phase | L3 | M, L |
|
Recognize that being security aware and understanding the importance of addressing security during software development needs to be a cultural norm (beliefs, behaviors, capabilities, actions) | L4 for information security; L3 for software security | E, M, L |
| |
Characteristics of software security at the governance/management level | Engage leaders to better appreciate and understand the characteristics and actions necessary to address software security as governance and management concerns, and the consequences of not doing so | L4 for information security; L3 for software security | E, M, L |
|
Establish a framework and roadmap for addressing software security as an enterprise-wide undertaking, and identify some of the pitfalls and barriers to tackle head on | L3 | E, M, L |
| |
Software security included in software development measurement process | Determine how to include security as part of a software development measurement process, including suggested process and product measures, and implement, track, and report such measures | L1 | M, L |
|
John Steven states [Steven 2006]:
Don’t demand teams to begin conducting every activity on day one. Slowly introduce the simplest activities first, then iterate.
[Have] patience. It will take at least three to five years to create a working, evolving software security machine. Initial organization-wide successes can be shown within a year. Use that time to obtain more buy-in and a bigger budget.
Clearly, there is no one-size-fits-all approach to software security. Project managers and their teams need to think through the choices, define their tradeoff and decision criteria, learn as they go, and understand that this effort requires continuous refinement and improvement.
The U.S. Department of Homeland Security Software Assurance Program has sponsored and provided access to a number of reports that contain additional guidance on software assurance practices in general and for project management, acquisition, and workforce competency development in particular. Downloadable current versions and drafts for review are available on the BSI Web site [BSI 47].
We’ll leave you with the five key take-away points introduced in the preface. We trust you now better understand these and can use them to build a sense of urgency and a better business case for software security engineering:
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.
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 determine what is good enough, understanding that software security risks will change throughout the SDLC.
Building secure software depends on understanding the operational context in which it will be used.
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 how software can better resist, tolerate, and recover from attack.