CORAS representation Sample Clauses
The CORAS representation clause defines how information, processes, or data are to be depicted using the CORAS modeling language or methodology. In practice, this clause may require parties to use specific diagrammatic conventions, symbols, or templates associated with CORAS when documenting risk assessments or system analyses. By standardizing the way information is represented, the clause ensures consistency, clarity, and facilitates effective communication among stakeholders involved in risk management or system design.
CORAS representation. The CORAS fragment is identical to Figure 16 presented in Section 7.2.1.
CORAS representation. Figure 21 shows a fragment of a CORAS diagram showing two nodes (threat scenarios S1 and S2) that may each lead to another node (threat scenario S3). This is represented by the 'leads-to' relation from each of S1 and S2 to S3. The likelihood of S3 thus depends on the likelihood of S1 and the conditional likelihood of an occurrence of S1 actually leading to an occurrence of S3, and similarly for S2. Notice that the diagram is meant to represent an example of a more general case, where one or more nodes may lead to another node. Moreover, even if all nodes in this particular fragment are threat scenarios, each of them could equally well have been replaced by an incident without having any impact on the reasoning presented here. The likelihood contribution from S1 to S3 again has two direct sub-nodes, showing that it depends on the likelihood of S1 (l_S1) as well as the conditional likelihood of an occurrence of S1 actually leading to S3 (cl_S1_to_S3). Similarly, the likelihood contribution from S2 to S3 depends on the likelihood of S2 (l_S2) as well as the conditional likelihood of S2 leading to S3 (cl_S2_to_S3). Figure 22 shows only one example, where there are two incoming branches to S3. In general, the number of direct sub-nodes to S3 will be equal to the number of incoming branches. However, it is important to avoid having to too many incoming branches to a node, as this makes it hard to define the utility function. When using five-step scales as in the example, even three incoming branches would give 125 possible combinations. This is can already be hard to handle, and more branches would be completely unfeasible. In such cases, we recommend restructuring the model, as further explained in the DEXi manual [1]. Observe that the nodes representing likelihoods of S1 and S2 occur at the bottom/leaf layer of the DEXi fragment in Figure 22. As these may again depend on incoming branches, the model allows any finite number of levels in the DEXi tree.
CORAS representation. A risk is the likelihood of an incident and its consequence for an asset. Hence, in order to assess the risk level, we need to assess the likelihood of the incident and its consequence for the asset in question. Figure 18 illustrates how a risk is represented in a CORAS threat diagram as a combination of an incident, an asset, and an 'impacts'-relation from the incident to the asset. Our naming convention is shown in 0. Notice that the square brackets are normally used to hold likelihood and consequence assessments. We have inserted the variable/node names to be used in the corresponding DEXi fragment, in order to make it easier to understand the connection.
CORAS representation. Indicators can be attached to a 'leads-to' relation from one node to another to show that the indicators are used as input for assessing the conditional likelihood of an occurrence of the source node leading to the target node. Normally, this is done by attaching the indicators to a vulnerability on the 'leads-to relation', as the indicators typically say something about the presence or severity of the vulnerability. Figure 25 shows a fragment of a CORAS diagram where two indicators, I1 and I2, have been attached to a vulnerability on the 'leads-to' relation between two nodes. The root node (cl_S1_to_S2) represents the conditional likelihood that an occurrence of the source node (S1) will lead to the target node (S2). Here, there is one direct sub-node to the root node for each attached indicator. Hence, the likelihood of the root node (cl_S1_to_S2) depends on these indicators. As for the case with indicators attached to a node, before the utility function of cl_S1_to_S2 can be defined, we have to define an ordered scale for each indicator. This is done in the same way as described in Section 9.3.
CORAS representation. Indicators can be attached to a node in order to show that the indicators are used as input for assessing the likelihood of the node. Figure 18 shows a fragment of a CORAS diagram where two indicators, I1 and I2, have been attached to a node S1. The indicators are represented as 'notes', where the colour denotes the indicator type. However, the indicator type is not important for our purposes here, as they are all treated the same with respect to the guidelines. Notice that in CORAS diagrams, a branch always starts with a threat initiating a node. However, we rarely assign likelihoods to the threats themselves or to the 'initiates' relation from a threat to a node, but rather to the node. Any indicators assigned to a threat or to an 'initiates' relation can therefore be handled as if it was assigned directly to the node, following the guidelines of this subsection. Figure 19 shows a DEXi fragment corresponding to the CORAS fragment in Figure 18. 2 This restriction can, however, be lifted if we assume that one occurrence of the source node can lead to several occurrences of the target node. Here, there is one direct sub-node (which is also a leaf-node, and hence shown as a triangle) to the root node for each attached indicator. Hence, the likelihood of the root node (l_S1) depends on these indicators. Before the utility function of l_S1 can be defined, an ordered scale has to be defined for each indicator. Although the indicators do not necessarily represent a likelihood, we make sure to define the scale in such that a low value implies a low risk contribution. For example, assume that a threat scenario representing initiation of a HTTP Request/Response splitting is included in a risk model for client-server protocol manipulation. To this threat scenario, we attach the indicator 'Has any network reconnaissance attempt been detected in the past?' Since this is a yes/no question, the scale for the indicator only has two steps: Yes and No. A positive answer may indicate that someone has tried to prepare for an attack, and hence an increased likelihood. Therefore, for this indicator scale, the order from lowest to highest value would be No; Yes.
CORAS representation. CORAS diagrams can be used to show risk mitigation options by attaching these to the different elements of a risk model. Figure 27 shows such a diagram.
CORAS representation. CORAS diagrams can be used to show risk mitigation options by attaching these to the different elements of a risk model. Figure 22 shows such a diagram. Here, the mitigation option M1 is attached to threat scenario S1, indicating that implementing M1 will reduce the likelihood of S1, which could also reduce the likelihood of U1, and hence the associated risk.
CORAS representation. Indicators can be attached to a node in order to show that the indicators are used as input for assessing the likelihood of the node. Figure 23 shows a fragment of a CORAS diagram where two indicators, I1 and I2, have been attached to a node S1. The indicators are represented as 'notes', where the colour denotes the indicator type. However, the indicator type is not important for our purposes here, as they are all treated the same with respect to the guidelines. 2 This restriction can, however, be lifted if we assume that one occurrence of the source node can lead to several occurrences of the target node.