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

Use of codes of practice

“A written set of rules that, when correctly applied, can be used to control one or more specific hazards.”

Codes of practice must:

  • be widely acknowledged in the specific domain;

  • be relevant for the control of the considered hazards, meaning that it has been successfully applied in similar situations;

  • be publicly available for all actors who want to use them, not necessarily free of charge.

Codes of practice cover documents described as standards, procedures or rule books, for railways, for example:

  • Technical Specifications for Interoperability (TSIs);

  • National Technical Rules and National Safety Rules;

  • Rail Industry Standards;

  • British Standards, Euronorms, and other international standards;

  • Network Rail company standards;

  • Association of Train Operating Companies (ATOC) standards;

  • Etc.

Codes of practice are rarely written just to control hazards – they are normally also written to deliver other benefits such as efficiency, interoperability, and reliability.

When

  • Safety measures from the codes of practice appropriately cover the hazard, and;

  • The codes of practice are fully complied with.

Then

  • The safety measures from the codes of practice are considered safety requirements for the hazard;

  • Record the reasons for believing that the safety requirements from the codes of practice appropriately cover the hazard;

  • Add the safety requirements in the system definition.

Last updated 1 year ago