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
  • Semi-quantitative estimation
  • Tables
  • Likelihood
  • Consequence
  • Frequency/Consequence
  • Calibrating the risk matrix
  1. Safety (and Security)

Qualitative risk estimation

The classification of a hazard is made based on expert judgment.

In practice, this can be undertaken via the collective opinion of the attendees at a hazard identification workshop.

For a straightforward hazard:

  • Identify the causes of the hazard and document them as a table or short explanation;

  • Identify the possible consequences of the hazard and the factors that affect those consequences, and document as a table or short explanation;

  • Identify the existing safety measures that control the hazard;

  • Identify the practical additional safety measures that might be implemented to control the hazard further.

Semi-quantitative estimation

  • Used when some data is available, or a good degree of judgment can be applied to estimates of the frequency and consequences of each accident;

  • Typically uses a 5 x 5 matrix with the frequency and consequence rankings broadly separated by a fixed factor, but this does not have to be the case;

  • The size of the matrix and the factor difference in frequency and consequence rankings should suit a particular stakeholder’s operation.

The main advantages of using a risk matrix:

  • It is an easily understandable representation of relative risk levels;

  • A tie can be applied relatively quickly;

  • It is readily understandable by those whose inputs and opinions are needed to apply it;

  • It enables the combination of frequency and consequences to be represented in an intuitive visual way.

The explicit risk estimation involves:

  • Identifying the possible causes of the hazard and estimating the likelihood of each cause resulting in an accident;

  • Identifying the possible consequences of the hazard and assessing their severity.

Tables

Likelihood

Ranking
Category
Description

5

Frequent or almost certain

Event occurs many times during the period of the project (or life of the facility).

4

Likely

Event likely to occur once or more during the period of the project (or life of the facility).

3

Possible

Event could occur during the period of the project (or life of the facility).

2

Improbable

1

Higly improbable

Consequence

Ranking
Category
Description

5

Catastrophic

A “catastrophic accident” means an accident typically affecting a large number of people and resulting in multiple fatalities and/or major damage to the environment.

4

Critical

A “critical accident” means an accident typically affecting a very small number of people and resulting in at least one fatality.

3

Moderate

Small injuries requiring medical treatment and some lost time.

2

Minor

Minor injuries, first aid only required.

1

Insignificant

No injuries or negligible social cultural impacts.

Frequency/Consequence

Frequency/Consequence

1 - Insignificant

2 - Minor

3 - Moderate

4 - Critical

5 - Catastrophic

5 - Frequent or almost certain

6

7

8

9

10

4 - Likely

5

6

7

8

9

3 - Possible

4

5

6

7

8

2- Improbable

3

4

5

6

7

1 - Highly improbable

2

3

4

5

6

8 - 10

Intolerable

Risks considered Intolerable shall be eliminated.

7

Undesirable

  • Accepted only when risk reduction is impracticable and with the agreement of the Safety Regulatory Authority (SFA), as appropriate.

  • Action plans must be developed with clear assignment of individual responsibilities and timeframes.

5 - 6

Tolerable

  • Acceptable with adequate control and with the agreement of the SFA.

  • Risk requires specific ongoing monitoring and review, to ensure level of risk does not increase. Otherwise manage by routine procedures.

2 - 4

Negligible

  • Acceptable with/without the agreement of the Safety Regulatory Authority.

  • Risk can be accepted or ignored. Manage by routine procedures, however unlikely to need specific application of resources.

Calibrating the risk matrix

Risk classification matrices are used for ranking and comparing the risk of different hazards.

The matrix must be calibrated so that relative risk of different hazard is preserved across the various risk classifications.

  • Achieved by having the same factor difference (a factor of 5) between each frequency and consequence category.

Once in
No / year

Frequent or almost certain

12 days

31.25

5

Likely

2 months

6.25

4

Possible

9 months

1.25

3

Improbable

4 years

0.25

2

Highly improbable

20 years

0.25

1

Last updated 1 year ago

Event is unlikely to occur, but it is possible. Means an occurrence of failure at a frequency less than or equal to per operating hour.

May occur only in exceptional circumstances. Means an occurrence of failure at a frequency less than or equal to per operating hour.

10−710^{-7}10−7
10−910^{-9}10−9