Notes - MCS
Robust Software
Notes - MCS
Robust Software
  • Robust Software
  • Secure Software Design Principles
    • Motivation
    • Secure and Resilient/Robust Software
    • Best Practices for Resilient Applications
    • Designing Applications for Security and Resilience
    • Architecture for the Web/Cloud
  • Software Security Lifecycle
    • Motivation
    • Secure Development Lifecycle
    • Software Security Touchpoints
    • Software Assurance Forum for Excellence in Code (SAFECode)
    • Secure SW Lifecycle Processes Summary
    • Adaptations of the Secure Software Lifecycle
    • Assessing the Secure Software Lifecycle
    • Recommendations
  • Software Quality Attributes
    • Motivation
    • Software Quality Assurance
    • Software Quality Standards
    • Software Quality Attributes
    • Extra Software Quality Assurance Properties
  • Security Requirements
    • Motivation
    • Security Requirements
    • Threats
    • Defenses
    • Confidentiality
    • Integrity
    • Availability
    • What about other goals/properties?
    • Security Requirements Engineering
    • Types of Security Requirements
    • Security Policy
    • Precision
    • Completeness and Consistency
    • Examples of Non-Functional Requirements
    • Goals and Requirements
    • Measures
    • Requirements Interaction
    • Natural Language Requirements
    • Best Practices
  • Common Software Attacks
    • Objectives
    • 10 Major Cyber-Attacks of 21st Century
    • Software Security Basics
    • Defenses Methods
    • SANS SWAT Checklist
  • Safe Programming
    • Secure Coding Practices
    • Top 10 Secure Coding Practices (CERT/SEI)
    • 7 Pernitious Kingdoms
  • Robustness, PenTest, Fuzzy and Static Code Analysis
    • Security/Robustness Testing
    • Robustness Tests Checklist Example
    • Penetration Testing
    • Penetration Testing Roadmap
    • Tools
    • Fuzz Testing
    • Static Code Analysis
    • Side Channels
  • Safety (and Security)
    • Safety
    • A safety Lifecycle Example
    • Risk Management Process
    • System Definition
    • Hazard Identification and Classification
    • Desk-based Hazard Identification
    • Workshop-based Hazard Identification
    • HAZOP
    • Hazard Identification and Classification
      • Broadly acceptable risks
    • Risk Evaluation and Risk Acceptance
    • Use of codes of practice
    • Use of reference system
    • Explicit risk estimation
    • Qualitative risk estimation
    • Quantitative risk estimation
    • Safety measures
    • Safety requirements
    • Hazard Management
    • Hazard life cycle
    • Independent Assessment
    • Safety Plan
    • Safety Case
    • FMEA Example
    • DevSecOps
Powered by GitBook
On this page
  • SAMM
  • BSIMM
  • CC
  1. Software Security Lifecycle

Assessing the Secure Software Lifecycle

There are different assessment approaches to evaluate the maturity of the secure development lifecycle:

  • Software Assurance Maturity Model (SAMM).

  • Building Security in Maturity Model (BSIMM).

  • Common Criteria (CC).

SAMM

Assessment of a development process.

  1. Define and measure security-related activities within an organization.

  2. Evaluate their existing software security practices.

  3. Build a balanced software security program in well-defined iterations.

  4. Demonstrate improvements in a security assurance program.

Uses 12 security practices grouped into one of 4 business functions.

  • Governance

  • Construction

  • Verification

  • Deployment

Provides an organization maturity level (0 to 3).

BSIMM

Assessment of a development process based on SAMM

Uses 12 security practices grouped into one of 4 business functions;

  • Governance

  • Intelligence

  • Secure software development lifecycle touchpoints.

  • Deployment

Provides comparison to other BSIMM-assessed companies.

CC

Provides means for international recognition of secure information technology.

Authorized Certification/ Validation Body.

Reuse of certified/ validated products with no further evaluation.

Based on Evaluation Assurance Levels (EAL):

  1. Functionally tested.

  2. Structurally tested.

  3. Methodically tested and checked.

  4. Methodically designed, tested, and reviewed.

  5. Semi-formally designed and tested.

  6. Semi-formally verified design and tested.

  7. Formally verified design and tested.

Last updated 1 year ago