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
  • Quality Management Report
  • Technical Safety Report
  • Report structure
  1. Safety (and Security)

Safety Case

Is the key document that documents demonstration that the product complies with the specified safety requirements.

Evidence can be shown in related documents, all referred in the Safety Case.

Should cover:

  • Technical requirements;

  • Quality processes;

  • Safety Processes.

Concludes unequivocally on if and how the system complies with the expected SIL (Safety Integrity Level).

Identifies and describes (or points to the description) on all the open points an SRACs.

Quality Management Report

  • Shows evidence of the control of quality of the system by an effective Quality Management System (QMS).

  • QMS purpose is to minimize the incidence of human errors at each stage of the lifecycle and should be applicable throughout the system lifecycle.

  • Examples of aspects which should be controlled by the quality management system and included in the Quality Management Report

    • organisational structure;

    • quality planning and procedures;

    • specification of requirements;

    • design control;

    • design verification and reviews;

    • application engineering;

    • procurement and manufacture;

    • product identification and traceability;

    • handling and storage;

    • inspection and testing;

    • non-conformance and corrective action;

    • packaging and delivery;

    • installation and commissioning;

    • operation and maintenance;

    • quality monitoring and feedback;

    • documentation and records;

    • configuration management/change control;

    • personnel competency and training;

    • quality audits and follow-up;

    • decommissioning and disposal.

  • Shows evidence of the management of the safety of the system by an effective safety management process.

  • Safety management process purpose is to minimize the incidence of safety-related human errors at each stage of the lifecycle.

  • The Safety Management Report must include all documentary evidence for this process, either directly or by reference to other documents.

  • The process should be consistent with the defined in EN 50126 in areas like RAMS management, hazard analysis, and risk assessment.

  • Should include, but not necessarily limited to, the following elements:

    • Safety lifecycle;

    • Safety organization;

    • Safety plan;

    • Hazard log;

    • Safety requirements specification;

    • System design;

    • Safety reviews;

    • Safety verification and validation;

    • Safety justification;

    • System handover;

    • Operation and maintenance;

    • Decommissioning and disposal.

Technical Safety Report

Consists of technical evidence of the safety of the system design (product), complementing the evidence of quality and safety management (process).

Should explain the technical principles that assure the safety of the design, including supporting evidence (design principles and calculations, test specifications and results, and safety analysis).

Report structure

Introduction

Overview description of the system including summary of technical safety principles and the extent to which the system is claimed to be safe. It should also indicate the applicable standards and respective issues

Assurance of correct operation

Evidence of the system's correct operation according to its operational and safety requirements, including the following aspects:

  • System architecture description;

  • Definition of interfaces;

  • Fulfillment of System Requirements Specification;

  • Fulfillment of Safety Requirements Specification;

  • Assurance of correct hardware functionality;

  • Assurance of correct software functionality.

Effects of faults

Evidence that the occurrence of random and systematic faults does not reduce the safety of the overall system, including the following aspects:

  • Effects of single faults;

  • Independence of items;

  • Detection of single faults;

  • Action following detection (including retention of safe state);

  • Effects of multiple faults;

  • Defense against systematic faults.

Operation with external influence

Demonstrate that when subjected to external influences the system continues to fulfill its specified operational and safety requirements (including fault conditions).

Safety-related application conditions

Specify the rules, conditions, and constraints to be observed in the application of the system.

Safety qualification tests

Evidence to demonstrate successful completion, under operational conditions, of the Safety Qualification Tests.

Last updated 1 year ago