PROCESS VIEW

With the exceptions explained below, the white boxes represent individual processes of ISO/IEC 15288, System Life Cycle Processes, and ISO/IEC 12207, Software Life Cycle Processes.

• The items marked with a bullet are concerns of software assurance. They do not necessarily appear in 15288 or 12207 and have been binned into appropriate processes of 15288 and 12207.
• 15288 and 12207 use slightly different names for their Technical Processes. The names in 12207 are software-specialized. In this chart, the 15288 names are used.
• Verification and Validation are distinct processes in 15288 and 12207. In this chart they have been combined because the software assurance techniques used in both will be similar.
• The terms Organization, Project, and Engineering are not used to group processes in 15288 and 12207. They are introduced here to indicate a hierarchy of interests.
• The term Operations and Sustainment is not used in 15288 and 12207. It is introduced here to align with sponsor terminology.
• Neither 15288 nor 12207 claims to provide a complete set of organization-level processes. The Governance processes on this chart are not based on 15288 or 12207.
• The Risk Management process of 15288 and 12207 is suitable for all forms of risk management, including project risk, risk to operation, and enterprise level risk. On this chart a distinct enterprise process is shown so that different concerns can be highlighted.

• Security Is Not Just a Technical Issue
• Governance and Management References
• Framing Security as a Governance and Management Concern: Risks and Opportunities
• How Much Security Is Enough?
• Maturity of Practice and Exemplars
• Making Business-Based Security Investment Decisions —A Dashboard Approach
• Estimating Benefits from Investing in Secure Software Development
• Business Considerations and Foundations for Assuring Software Security: Business Case Models for Rational Action
• Calculating Security Return on Investment
• Models for Assessing the Cost and Value of Software Assurance
• Making the Business Case for Software Assurance
• A Common Sense Way to Make the Business Case for Software Assurance
• It's a Nice Idea but How Do We Get Anyone to Practice It? A Staged Model for Increasing Organizational Capability in Software Assurance
• What Measures Do Vendors Use for Software Assurance?

• Assuring Software Systems Security: Life Cycle Considerations for Government Acquisitions
• Maturity Framework for Assuring Resiliency Under Stress
• Secure Software Development Life Cycle Processes
• Correctness by Construction
• Strengthening Ties Between Process and Security

• Assuring Software Systems Security: Life Cycle Considerations for Government Acquisitions
• Acquisition Overview: The Challenges
• Building Security into the Business Acquisition Process
• System-of-Systems Influences on Acquisition Strategy Development
• Finding a Vendor You Can Trust in the Global Marketplace
• Architectural Risk Analysis
• Architectural Risk Analysis — Business Case
• Architectural Risk Analysis — References
• What Measures Do Vendors Use for Software Assurance?

• Security and Project Management
• The Influence of System Properties on Software Assurance and Project Management
• Assurance Cases Overview
• Arguing Security — Creating Security Assurance Cases
• Evidence of Assurance: Laying the Foundation for a Credible Security Case
• Estimating Benefits from Investing in Secure Software Development
• Business Considerations and Foundations for Assuring Software Security: Business Case Models for Rational Action
• Calculating Security Return on Investment
• Models for Assessing the Cost and Value of Software Assurance
• Making the Business Case for Software Assurance
• A Common Sense Way to Make the Business Case for Software Assurance
• It's a Nice Idea but How Do We Get Anyone to Practice It? A Staged Model for Increasing Organizational Capability in Software Assurance
• Maturity Framework for Assuring Resiliency Under Stress

Attack modeling (misuse and abuse cases)

• Trustworthy Composition: The System Is Not Always the Sum of Its Parts
• Identity in Assembly and Integration
• Security Concepts, Challenges, and Design Considerations for Web Services Integration
• Introduction to Attack Patterns
• Attack Pattern Generation
• Attack Pattern References
• Attack Pattern Usage
• Further Information on Attack Patterns
• Attack Pattern Glossary

Sw security requirements

• Requirements Engineering Annotated Bibliography
• SQUARE Process
• The Common Criteria
• Security Requirements Engineering
• Requirements Elicitation Case Studies Using IBIS, JAD, and ARM
• Requirements Elicitation Introduction
• Requirements Prioritization Case Study Using AHP
• Requirements Prioritization Introduction
• Optimizing Investments in Security Countermeasures: A Practical Tool for Fixed Budgets

Requirements analysis/Risk-based derived requirements

• Risk Management Framework References
• Risk Management Framework: Business Case
• Risk Management Framework Glossary
• Risk Management Framework (RMF)

Secure Sw architectural design

• Identity in Assembly and Integration
• Security Concepts, Challenges, and Design Considerations for Web Services Integration
• Defense in Depth
• Economy of Mechanism
• Failing Securely
• Least Common Mechanism
• Least Privilege
• Never Assuming that Your Secrets Are Safe
• Promoting Privacy
• Psychological Acceptability
• Reluctance to Trust
• Securing the Weakest Link
• Separation of Privilege
• Design Principles
• Correctness by Construction

Architectural design/Risk-based architectural analysis

• Architectural Risk Analysis

Architectural design/Secure Sw detailed design and analysis

• Use Authentication Mechanisms, Where Appropriate, Correctly
• Use Authorization Mechanisms Correctly
• Ensure that the Bounds of No Memory Region Are Violated
• Guidelines Overview
• Ensure that Input Is Properly Canonicalized
• Follow the Rules Regarding Concurrency Management
• Design Configuration Subsystems Correctly and Distribute Safe Default Configurations
• Use Well-Known Cryptography Appropriately and Correctly
• Clear Discarded Storage that Contained Secrets and Do Not Read Uninitialized Storage
• Carefully Study Other Systems Before Incorporating Them into Your System
• If Emulation of Another System Is Necessary, Ensure that It Is as Correct and Complete as Possible
• Handle All Errors Safely
• Be Suspicious about Trusting Unauthenticated External Representation of Internal Data Structures
• Do Not Use the "%n" Format String Specifier
• Treat the Entire Inherited Process Context as Unvalidated Input
• Never Use Unvalidated Input as Part of a Directive to any Internal Component
• Do Not Perform Arithmetic with Unvalidated Input
• Assume that Human Behavior Will Introduce Vulnerabilities into Your System
• Correctness by Construction

Secure coding and Sw construction

• OpenBSD
• SafeStr
• Strsafe.h
• Vstr
• Windows XP SP2
• Arbitrary Precision Arithmetic
• Compiler Checks
• C++ std::string
• fgets() and gets_s()
• Guard Pages
• Heap Integrity Detection
• memcpy_s() and memmove_s()
• Null Pointers
• Coding Practices
• Phkmalloc
• Randomization
• Range Checking
• Detection and Recovery
• Runtime Analysis Tools
• Safe Integer Operations
• strcpy() and strcat()
• strcpy_s() and strcat_s()
• OpenBSD's strlcpy() and strlcat()
• strncpy() and strncat()
• strncpy_s() and strncat_s()
• Strong Typing
• Consistent Memory Management Conventions
• strlcpy() and strlcat()

Implementation/Security code review and static analysis

• Code Analysis
• Source Code Analysis Tools — Business Case
• Source Code Analysis Tools — Overview

Sw component integration

• System-of-Systems Influences on Acquisition Strategy Development
• Trustworthy Composition: The System Is Not Always the Sum of Its Parts
• Assembly and Integration Case Study: Enterprise Patch Management
• Identity in Assembly and Integration
• Evolutionary Design of Secure Systems — The First Step Is Recognizing the Need for Change
• Security Concepts, Challenges, and Design Considerations for Web Services Integration

Risk analysis of Sw reuse components

• Security Considerations in Managing COTS Software
• Assessing Security Risk In Legacy Systems
• Software Security in Legacy Systems

Risk-based test planning

• Risk-Based and Functional Security Testing

Security-enhanced test and evaluation

• Individual Certification of Security Proficiency for Software Professionals: Where Are We? Where Are We Going?
• Black Box Security Testing Tools

Security-enhanced test and evaluation/Penetration testing

• Adapting Penetration Testing for Software Development Purposes
• Penetration Testing Tools

Transition/Secure software environment (secure configuration, application monitoring, code signing, etc)

• Deploying and Operating Secure Systems
• Plan, Do, Check, Act
• Risk-Centered Practices
• Integrating Security and IT
• Prioritizing IT Controls for Effective, Measurable Security
• Navigating the Security Practice Landscape
• Deployment & Operations References

Incident handling and response

• Incident Management
• The Role of Computer Security Incident Response Teams in the Software Development Life Cycle
• Defining Computer Security Incident Response Teams

Defect tracking and remediation

• Maturity Framework for Assuring Resiliency Under Stress
• Predictive Models for Identifying Software Components Prone to Failure During Security Attacks

Vulnerability and patch management

• Assembly and Integration Case Study: Enterprise Patch Management