## 3 Security Evaluation Methodology for ICT Systems
### Risk Identification  
Once the general claims have been established, the next step is to identify the specific ones relevant to the TOE. The goal of the _risk identification_ phase is to break down the system into its components, determine the applicable security properties and claims for each of them, and define the security tests needed to validate these claims. This phase transitions from a high-level understanding of the system to a more detailed, component-specific view, which is critical for the following security assessment and testing phases. Figure 3 describes the proposed scheme for identifying risks following the well known Unified Modeling Language (UML) notation, moving from a broad, abstract description of the system to detailed security tests for each component. The process can be summarized as follows:  
(1) From system to security properties: Each system is evaluated against authentication, authorization, non-repudiation, confidentiality, integrity, and availability based on the well-known STRIDE taxonomy. Using this taxonomy simplifies the creation of a visual security label later in the process, as the security level will be quantified for each of the categories. It is important to note that not all security properties will apply to every system. For example, if a system does not interact with external resources or entities, the authorization property may not be relevant. (2) From system security properties to components: Systems may consist of a single component (e.g., a device) or multiple interconnected components, each of which may affect one or more security properties. In this step, we identify the components that compose the system and their associated security properties. This mapping helps to identify which parts of the system require specific security tests. (3) From components to applicable claims: Once the components are identified, we select the claims applicable to each one of their security properties. The set of claims we identified has already been classified following the STRIDE taxonomy, facilitating this process for the security evaluator. (4) From generic claims to vulnerability-based claims: Some claims are directly linked to known vulnerabilities (e.g., \"C32: The source code must not use components with known vulnerabilities\"). These vulnerabilities can be identified from public databases such as the NVD, Common Weakness Enumeration (CWE) ([[https://cwe.mitre.org](https://cwe.mitre.org)]([https://cwe.mitre.org](https://cwe.mitre.org)) accessed on 3 February 2025), and Common Vulnerabilities and Exposures (CVE) ([[https://cve.mitre.org](https://cve.mitre.org)]([https://cve.mitre.org](https://cve.mitre.org)) accessed on 3 February 2025). When a vulnerability is identified, it is assigned a predefined risk score (e.g., using CVSS) on a scale from 0 to 10. The security expert may refine this score based on the specific characteristics of the component and its usage context. (5) From claims to security tests: Once the vulnerabilities and claims have been identified, the next step is to define the tests required to validate them. For vulnerability-based claims, tests are designed to verify whether the identified vulnerabilities are present in the system. For test-based claims, relevant tests are developed to ensure that the system meets the security requirements for each claim. Figure 3: Decomposition of the system. At the end of the process, we decompose the TOE evaluation in a tree (Figure 3) in which the leaves represent the specific security tests to be developed and executed in subsequent phases. This phase also analyses the dependencies between components in order to identify any cascade effects and highly sensitive components within the system; that is, components that depend on a wide number of other components and are more prone to failures. Therefore, a sensitivity metric between 0 and 10 is assigned to each component of the system. The higher the sensitivity value, the more likely the component is to be impacted by cascade effects.