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
  1. Safety (and Security)

Use of reference system

Comparison with reference system(s) principle:

  • Compare a new system against an existing system which is known to be associated with an acceptable level of risk;

  • If the systems are sufficiently similar that there is no additional risk associated with the new system, then the risk from it is considered acceptable;

  • The safety measures from the reference system will be adopted by the new system as safety requirements.

The reference system must:

  • have been proven in use to have an acceptable safety level and would still qualify for approval in the Member State where the system is to be introduced;

  • have “similar” functions and interfaces as the system under assessment;

  • be used under “similar operational conditions” as the system under assessment;

  • be used under “similar environmental conditions” as the system under assessment.

Steps:

  1. The risks associated with the hazards covered by the reference system are considered as acceptable;

  2. The safety measures from the reference system will be adopted by the new system as safety requirements;

  3. These safety requirements are registered in the hazard record as safety requirements for the relevant hazards.

Deviation from the reference system

In case of deviation of the systems, the risk evaluation shall demonstrate that the system under assessment reaches at least the same safety level as the reference system;

One way of carrying out this approach is:

  • Identify all differences between the systems that might affect risk;

  • Identify all differences between the operational and environmental conditions that might affect risk;

  • For each difference in both lists assess if it would make the risk higher or lower;

  • If the results of the previous step demonstrate that the risk associated with the hazard is not greater in the SUA, then the risk associated with that hazard is accepted. The level of risk met by the reference system sets the risk assessment criteria.

Last updated 1 year ago