Skip to content
BoKSA

CYBOK 02.5-6 Risk Analysis Methods & System Thinking

CYBOK 02.5-6 Risk Analysis Methods & System Thinking

Relevant learning outcomes

Analysing • Advising • Designing

Possible products

  • Risk Assessment
  • Threat Model
  • Security Architecture Review
  • Security Requirements
  • System Analysis
  • Attack Surface Analysis

These products can also be used as portfolio evidence.

1. Introduction

Knowing what risk is is only the first step. As a cyber security professional you also need to determine where risks originate and how to analyse them.

Traditional risk assessments often focus on individual assets such as servers or applications. Modern systems, however, consist of many interconnected components, cloud services, suppliers and people. Risks increasingly emerge from these interactions rather than from a single vulnerable component.

This section focuses on analysing complex systems and selecting an appropriate risk analysis method.

2. Choosing the Right Analysis Approach

Not every environment requires the same type of analysis.

Component-driven analysis

This approach analyses individual assets.

Examples include:

  • Web servers
  • Databases
  • Laptops
  • Active Directory
  • APIs

Questions you ask are:

  • What can fail?
  • What vulnerabilities exist?
  • Which threats exploit them?
  • What is the impact?

This approach works well when the environment is relatively simple and well understood.

System-driven analysis

Large organisations are not simply collections of individual systems.

Dependencies exist between:

  • People
  • Business processes
  • Software
  • Cloud services
  • Suppliers
  • Physical infrastructure

A security incident often results from several small failures occurring together.

Rather than asking:

Which vulnerability exists?

you ask:

Why was this failure possible within the entire system?

3. System Thinking

System Thinking views an organisation as one connected system.

A weakness may not exist inside one application, but in the interaction between:

  • Users
  • Administrators
  • Procedures
  • Technology
  • Suppliers

Example:

A phishing email succeeds because:

  • MFA was optional.
  • Users were never trained.
  • Passwords were reused.
  • Monitoring was disabled.

None of these problems alone caused the incident.

Together they did.

4. STAMP

One method for analysing complex systems is STAMP (Systems-Theoretic Accident Model and Processes).

STAMP assumes accidents are often caused by inadequate control rather than component failure.

Instead of identifying individual vulnerabilities, STAMP analyses:

  • Control structures
  • Responsibilities
  • Communication
  • Feedback loops
  • Decision making

This method is especially useful for:

  • Critical infrastructure
  • Healthcare
  • Aviation
  • Industrial control systems
  • Autonomous systems

5. Human Factors

Not every weakness is technical.

Many security incidents involve people.

Examples include:

  • Phishing
  • Social engineering
  • Weak passwords
  • Security fatigue
  • Unclear procedures

When analysing risks you should therefore include both technical and human vulnerabilities.

6. Concern Assessment

Technical risk is not always perceived the same way by stakeholders.

A Concern Assessment analyses how people experience risk.

Questions include:

  • Which risks concern stakeholders most?
  • Which risks are underestimated?
  • Where is trust lacking?
  • Which assumptions are incorrect?

Understanding these concerns helps organisations communicate security decisions more effectively.

7. Selecting the Appropriate Method

Different situations require different analysis techniques.

Situation Suitable approach

Single application Component-driven Office network Component-driven Cloud migration Combination Hospital infrastructure System-driven Smart factory System-driven Critical infrastructure STAMP

No single method works for every organisation.

Starting points

When analysing a system:

  • Identify all important system components.
  • Identify relationships between components.
  • Include people and business processes.
  • Determine dependencies.
  • Identify possible failure scenarios.
  • Explain why the chosen analysis method fits the situation.

Quality checklist

Check whether:

  • Your chosen analysis method matches the environment.
  • Both technical and human factors are analysed.
  • Dependencies between systems are considered.
  • Assumptions are clearly documented.
  • Recommendations follow logically from the analysis.

Further reading

  • BOKSA 02 Risk Management & Governance
  • STAMP Handbook
  • NIST SP 800-30
  • ISO/IEC 27005
  • NCSC Risk Management Guidance

Advanced (Level 3)

For complex cyber-physical systems you may also investigate:

  • System-Theoretic Process Analysis (STPA)
  • Bow-Tie Analysis
  • Attack Trees
  • Fault Tree Analysis (FTA)
  • Good Security Metrics (Jaquith)
  • Operational Technology (OT) risk assessment