## 3 Security Evaluation Methodology for ICT Systems
### Establishing the Context  
To effectively assess the security of a system, it is essential to establish a strong basis to identify potential vulnerabilities and security flaws. Traditional risk assessment approaches often depend on known vulnerabilities cataloged in databases such as the National Vulnerability Database (NVD) [28] and expert analysis. Although these are valuable sources, they may not fully capture the evolving threat landscape, especially for emerging technologies. Our methodology enhances this approach by incorporating not only known threats but also best practices and relevant security standards to form an initial set of security claims.  
Therefore, in this preliminary phase of _establishing the context_, we define the claims that will serve as a baseline to protect the system against both known and unknown threats. In total, we elicited 74 claims collected in [29]. Each claim has a description, a STRIDE and impact classification following our methodology, preconditions to apply the claim, dependencies on other claims, metrics to be collected, possible tests, and the sources from which the claim was obtained.  
\begin{table}
\begin{tabular}{l l l l} \hline \hline
**Phase** & **Standard** & **Concept** & **Purpose** \\ \hline \multirow{3}{*}{Establishing the context} & CC/EUCC [14] & EAL & Describe the depth of the evaluation \\ \cline{2-3}  & CC [14] & PP & Consider the context of the TOE \\ \hline \multirow{6}{*}{Risk assessment} & Any & Claims & Identify security requirements applicable to the TOE \\ \cline{2-3}  & ISO 29119 [6], & Process & Identify actions to perform during the risk assessment \\  & ETSI TR 101 583 [4] & & phase and synergies with security testing \\ \cline{2-3}  & ISO 26262-3 [24] & Impact & Estimate the safety impact \\ \cline{2-3}  & FMEA [25] & Impact & Estimate the operational impact \\ \cline{2-3}  & BSI 1004 - [26] & Impact & Estimate the financial impact \\ \cline{2-3}  & BSI PIA Guideline [27] & Impact & Estimate privacy and legislation impact \\ \hline \multirow{2}{*}{Security testing} & ISO 31000 [5], & & Identify actions to perform during security testing \\  & ETSI TR 101 583 & & phase and synergies with security risk assessment \\ \hline \multirow{2}{*}{Treatment} & MUD [7] & Format & Describe security mitigation policies to be enforced \\  & MUD [7] & Format & during operational time \\ \hline Communication & & & Identify actions to perform during communication \\ and monitoring & ETSI TR 101 583 & Process & and monitoring \\ \hline \hline \end{tabular}
\end{table}
Table 2: Standards that support the proposed methodology This phase also introduces the concept of Tolerance Profiles (TPs) to reflect the TOE's operational context. Similarly to PP in CC, these profiles define acceptable levels of risk across different security aspects within the specific operational context. Figure 2 shows an example of a tolerance profile. The TP specifies the tolerable risk levels for each security property such as a confidentiality risk ranging from 0 to 7. If the confidentiality risk evaluated exceeds the defined threshold of 7, the product would not be eligible for certification. Additionally, a security level coding system, ranging from A (most secure, green) to D (least secure, red), links these risk thresholds to certification in a visual way through the label (see Section 3.6). Finally, in this phase, we can also establish the depth of the evaluation to be carried out. For this, we can rely on the notion of EALs outlined in the CSA, EUCC, or CC.  
Figure 1: Overview of the proposed security evaluation methodology.  
Figure 2: Example of a tolerance profile (TP).