Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

ARCH.170 Identify security losses and threats

SM-3940 - Populate Confluence page for activity definition: ARCH.170 Finished

GoalProvide a consistent starting point for security risk analysis
Requirements met by this process step

RiL 114.0210 (and thereby ISO 27001)

Inputs

Selected parts of the RiL 114 series relevant to this activity

AMOD-106 Enterprise goals including measures of effectiveness

OutputsAMOD-131 Security loss and threat state model
Methodology

The main intended pattern is <non-threat state> makes transition to <threat state> which can lead to <loss state>. This transition is called a vulnerability occurrence.

Complementary patterns are:

  • <threat state>recovers to <non-threat state> (for situations where there is a successful mitigation, or the problem clears up by itself)
  • <non-threat state> persists in <non-threat state> (a transition that allows the modelling of the probability of successful mitigations - and hence completes the state diagram as a hidden Markov model where the sum of all outgoing transitions from a state has probability 1)
  • <threat state> persists in <threat state> (where the threat state is still active but a loss has not occurred)

The viewpoint definition for AMOD-131 indicates the detail of how this is captured in the analysis model.

Using the relevant source material and regulations (with reference to existing material in the DB security regulations), define a standard set of security losses.

In this activity, there is only the following to do:

  • For each security loss, define a standard set of threat states that can lead to the loss
  • For each threat state, define a corresponding non-threat state which is the exact opposite of the threat state
  • Define the possible transitions from threat states to losses
  • Assess the severity of losses
  • Derive, from the severity of a loss, the maximum tolerable occurrence rate of a threat state

Threat states must be expressed in terms of general security conditions that could lead to a loss, excluding any notion of a system failure. They can include reference to abstract concepts that are not risk-related, for example an operational plan.

Note: the intention here is not to create a working state model of the entire business, rather to reduce down to an abstract set the critical business losses caused by threat/vulnerability combinations and the mechanisms by which they happen, so that sufficient mitigations can be built into the operational concept. The focus is on identifying our abstract fundamental security needs, which will be apportioned further to the system and its technical components in later stages of the ARCH process.

Tools and non-human resourcesTeam for Capella
CardinalityOne-off with possibility of revisions
Completion criteria

The output view is complete i.e. sufficient losses and threat states have been covered

The output view includes elements that are required by DB regulations, where applicable

The output view conforms to its modelling rules

Design reviewARCH.R.2 Operational review - consolidated
Step done by (Responsible)Security expert
Provides input to/assists (Contributes)None identified
Uses outputs (Informed)None directly