Enhancing Security in International Data Spaces: A STRIDE Framework Approach

Abstract

The proliferation of Internet of Things (IoT) devices and big data has catalyzed the emergence of data markets. Regulatory and technological frameworks such as International Data Spaces (IDS) have been developed to facilitate secure data exchange while integrating security and data sovereignty aspects required by laws and regulations, such as the GDPR and NIS2. Recently, novel attack vectors have taken a toll on many enterprises, causing significant damage despite the deployed security mechanisms. Hence, it is reasonable to assume that the IDS may be just as susceptible. In this paper, we conduct a STRIDE threat analysis on IDS to assess its susceptibility to traditional and emerging cybersecurity threats. Specifically, we evaluate novel threats such as Man-in-the-Middle (MitM) attacks, compromised end-user devices, SIM swapping, and potential backdoors in commonly used open-source software. Our analysis identifies multiple vulnerabilities, particularly at the trust boundary (TB) between users and the IDS system. These include the traditionally troublesome Denial of Service (DoS) attacks, key management weaknesses, and the mentioned novel threats. We discuss the hacking techniques, tools, and associated risks to the IDS framework, followed by targeted mitigation strategies and recommendations. This paper provides a framework for performing a STRIDE-based threat analysis of the IDS. Using the proposed methodology, we identified the most potent threats and suggested solutions, thus contributing to the development of a safer and more resilient data space architecture.

1. Introduction

The Internet of Things (IoT) is a paradigm that envisions all the real objects and devices that may also contain electronic microchips being connected to the Internet. It is already present in many industrial, public service, and consumer domains and cross-domain applications. Wireless connectivity is currently predominant between the real object/device and the wireless data reader connected to an edge computing device and the Internet. There are currently approximately 18 billion IoT objects/devices worldwide, and the number is expected to surpass 40 billion by 2030 [1]. The trends show that IoT is expanding globally, as its market cap is expected to reach USD 12 trillion by 2030 [2].

Such a large number of various IoT objects/devices already generates an enormous amount of data, leading to many questions related to ethics, privacy and data protection [3]. Due to the recent boom in data analytics and Machine Learning (ML) fields, data have become a resource of strategic importance [4]. Therefore, there is a considerable demand for data on the market, but many challenges are also involved in the data business. To comply with the laws and regulations, in some cases, the data owners must be able to retain control over their data. For instance, under GDPR [5], the data subjects must be able to access, modify, and delete their data.

To ensure data sovereignty in the data market, as described by the EU’s data strategy [6], the International Data Spaces Association (IDSA) [7] is developing International Data Spaces (IDS) [8]. This framework enables data owners to retain control over their data through data usage policies while being able to charge for its usage. On the other hand, this framework enables data consumers to safely and legally use the data to improve their businesses. The IDSA provides documentation and implementation guidelines that specifically address security issues. Although the guidelines are already comprehensive enough, we argue that they still can be improved. We stress the need to assess and potentially improve the IDS’s security mechanisms in the wake of the recent cybersecurity incidents that caused havoc in many enterprises. The affected companies were well established and organized, so it is safe to assume that the IDS, still in the development phase, could fall victim to the same threats upon becoming operational.

Recently, large companies such as Disney suffered significant data breaches due to a single compromised user who downloaded an infected game modification [9]. The hackers consequently gained access to all the data on his computer, allowing them to breach his work account. Similarly, the MOVEit data breach in 2023 exposed millions of records by exploiting a vulnerability in a file transfer tool, while T-Mobile saw 37 million customers’ data leaked due to an exposed API [10,11]. In 2024, it was discovered that a widely used open-source software XZ utils contained a backdoor [12]. The backdoor allowed unauthorized users to compromise and control the OpenSSH Secure Shell Protocol (SSH) daemon process (sshd), enabling attackers to run arbitrary commands on the targeted system before the authentication stage, thereby gaining complete control over the system. In 2020, a series of Distributed Denial of Service (DDoS) attacks hit the New Zealand Stock Exchange, forcing it to suspend trading for several days. The attackers targeted the exchange’s infrastructure with a massive DDoS attack, causing a significant loss of service availability, thus undermining investor confidence [13]. Enterprise data marketplaces typically restrict access to improve security and reduce the risk of DDoS attacks. However, severe consequences can occur if users are compromised [14]. Recent Industry 4.0 studies show that network-based attacks represent the most significant threat [15]. Denial of Service (DoS), DDoS, and Man-in-the-Middle (MitM) attacks are the most prevalent among these. Furthermore, there has been a notable rise in the frequency of such attacks since 2017, highlighting the growing vulnerability of interconnected industrial systems. This increasing trend underscores the critical need for robust intrusion detection systems to counter these evolving threats.

In the wake of the mentioned prominent cybersecurity incidents involving data breaches and DDoS attacks, we stress the need to revisit the security mechanisms of the IDS. Currently, no IDS threat analysis is available due to the novelty of both threats and the IDS testbed. Hence, the first step toward building a secure system is to conduct a comprehensive threat analysis and map the identified threats to specific components and interactions within the IDS. This method provides insight into the system’s resilience against contemporary threats and serves as the foundation for enhancing IDS security in the future. In this paper, we assess IDS security through the lens of the STRIDE methodology to identify threats, which guide us to the identification of vulnerabilities. By categorizing threats, we provide a structured approach to pinpoint areas where vulnerabilities are likely to exist, guiding a more focused security assessment. We have chosen STRIDE because of its straightforward approach and suitability for a distributed system consisting of multiple components of different trust levels. Hence, we deem STRIDE capable of systematically addressing the novel threats. Although multiple newer and more sophisticated threat modeling methodologies exist, we cannot exploit their advantages due to the lack of detailed information about the system. Since the IDS is still under development, our threat analysis input arguments are relatively basic and general. We also assess the feasibility of vulnerability exploitation using state-of-the-art tools and techniques. The primary contribution of this paper lies in the threat analysis of the IDS, emphasizing novel threats through which recent major incidents have occurred. Additionally, we establish a framework for future threat identification. Lastly, based on the results, we propose improvements to IDS, contributing to developing a more secure framework. The remainder of the paper is organized as follows:

• Section 2 discusses background and state-of-the-art related work.
• Section 3 provides a deeper insight into the STRIDE methodology.
• Section 4 shows the results of the analysis and proposed mitigation strategies.
• Section 5 provides a thorough discussion of the results.
• Section 6 concludes the paper.

2. Background and Related Work

The proliferation of data-driven business models and various data generation, collection, storage, and retrieval technologies has led to the emergence of data space ecosystems that enable secure and sovereign data sharing among organizations. For this reason, there are currently numerous EU data space projects [16]. We choose to use the IDS testbed [8] as the reference for our analysis because it is an open-source project provided by the IDSA. The IDSA is a Germany-based non-profit organization comprising over 180 companies focused on establishing and promoting standards for data spaces [7]. Data spaces like the IDS aim to facilitate trustworthy data exchange while ensuring data sovereignty and compliance with regulations like the GDPR and the NIS2 directive. While GDPR focuses specifically on data security, NIS2 encompasses the security of the entire infrastructure, expanding the scope to the overall resilience of the systems and incident response capabilities.

The IDS connectors are a bridge between the IoT devices and the IDS, and they initially relied on Message Queuing Telemetry Transport (MQTT) to exchange messages in the JavaScript Object Notation (JSON) format [17]. Currently, the IDS components communicate using the IDS Communication Protocol 2 (IDSCP-2) [18] and Multipart messages [19]. The connectors play a crucial role in ensuring seamless and secure data integration across different devices and systems by managing data flow between various endpoints. They are responsible for enforcing data usage policies, maintaining data integrity, and facilitating interoperability across heterogeneous systems within the data space. Additionally, IDS connectors support trusted data exchange by authenticating the parties involved and encrypting data transmissions to prevent unauthorized access and tampering. This procedure ensures that data sovereignty is preserved, aligning with regulatory requirements and providing a secure foundation for data-driven business operations. However, as data spaces become more interconnected and complex, they also become more susceptible to security threats due to more components and complex interrelationships.

To address the security of such systems, a variety of well-established security frameworks and guidelines exist at a broader, systemic level. For instance, the NIST Cybersecurity Framework [20] provides a set of standards and best practices for identifying, protecting, detecting, responding to, and recovering from cyber incidents. Similarly, the ISO/IEC 27000-series [21] offers a comprehensive suite of controls and recommendations for managing information security within an organization. These widely recognized resources, along with IoT and Industrial IoT (IIoT) security principles outlined by ENISA [22] and industry standards like OWASP’s Application Security Verification Standard (ASVS) [23], contribute to a robust baseline of security considerations. Our work on IDS threat modeling draws on such established security principles, focusing them precisely on the unique challenges of the IDS.

2.1. IDS Security

Several studies have highlighted the challenges of securing data spaces. For instance, the authors of [14] discuss the security implications of data marketplaces and the importance of robust access control mechanisms. Similarly, Pedreira et al. [15] provides a comprehensive review of cybersecurity threats in Industry 4.0, emphasizing the prevalence of network-based threats such as DoS and DDoS attacks and MitM attacks. Our analysis builds upon these findings while also considering the novel attack vectors that caused recent major cybersecurity incidents.

To combat the cybersecurity challenges involved with data spaces, Veen et al. presented Mahiru [24]. It is a federated data exchange system, similar to the IDS concept, designed to enable secure, decentralized collaboration between multiple parties with varying levels of trust. Its strengths lie in its decentralized design, minimizing central trust dependencies, and using X.509 certificates to prevent spoofing and tampering. Its policy and registry replication provide redundancy, mitigating DDoS attacks by avoiding single points of failure. However, Mahiru faces challenges from MitM attacks involving reverse proxies, which render SSL/TLS protections ineffective. Additionally, endpoint malware could expose private keys and compromise the registry, leading to privacy breaches and the risk of DDoS attacks. Furthermore, there is the threat of backdoors in open-source software, which could introduce additional vulnerabilities. Although Mahiru offers protection against common threats, it is still susceptible to the same kinds of threats as the IDS.

Another potential solution for IDS security is MIRANDA [25]—a Security Orchestration and Automated Response (SOAR) system that can be applied to IDS to enhance its cybersecurity capabilities. It introduces features like automated threat detection, incident response, and Actionable Cyber-Threat Intelligence (ACTI) sharing, strengthening IDS’s security setup. MIRANDA also introduces network packet inspection through tools like Snort and Suricata and advanced analytics engines that leverage ML to help detect and mitigate threats like DDoS attacks. However, it does not necessarily fill all security gaps, as it comes with some weaknesses, including the risk of a single point of failure due to its centralized architecture and potential vulnerabilities from using open-source tools, which may introduce backdoors. While MIRANDA enhances overall security, endpoint vulnerabilities can still expose sensitive data. MitM attacks are not explicitly addressed, indicating that MIRANDA improves security but may leave certain novel threats unaddressed.

The IDS already possesses some security mechanisms, as compliance with GDPR is inherent to its design. Once it is operational, it will have to be NIS2-compliant. This primarily concerns the security of data in storage and transit, as secure and regulatory-compliant data exchange is the system’s primary purpose. Menz et al. [26] presented the criteria for the operational IDS environment consisting of technical requirements for the IDS components. The work primarily focuses on the IDS’s functionality and defining role-based privileges. Although the criteria are already very detailed, the report omitted threats such as MitM attacks and application-layer DDoS attacks that often cannot be detected by the methods applicable to the network-based attacks [27]. The certification criteria outline what security measures should be in place but may not explicitly model potential threats. These include modern hacking techniques and tools like the ones outlined in

Table 1. Tools and methods exploiting security vulnerabilities.

Tool/Method	Description
Evilginx [29]	A tool for conducting advanced phishing attacks by acting as a reverse proxy to intercept login credentials and session tokens, effectively bypassing Two-Factor Authentication (2FA) protection and SSL/TSL.
Linken Sphere browser [30]	A secure, anti-detection browser used for fraud and anonymity. It allows users to mask fingerprints and emulate different devices or browsers to evade detection. It allows for the maximal utilization of the stolen user data by allowing the hackers to appear as legitimate users in terms of device identification, geolocation, cookies, etc.
SIM swapping [31]	Typically, a social engineering attack where an attacker gains control of a victim’s phone number by convincing a mobile carrier to transfer the number to a new SIM card, allowing access to Two-Factor Authentication codes and other sensitive information.
Open-source projects with backdoors [32]	Sometimes malicious actors contribute code with hidden backdoors to open-source projects, which can later be integrated into enterprise software, introducing vulnerabilities within the organization.
Dark web markets [33]	Underground marketplaces where individuals anonymously buy and sell stolen credentials, hacking tools, and other illicit goods and services, facilitating a wide range of cybercriminal activities. These platforms offer large amounts of user data and allow potential buyers to search the data based on various parameters, including sites for which session cookies or other credentials exist.

. The way that the hackers utilize such tools is contextually described by the MITRE attack matrix for enterprise [28].

A novel, noteworthy problem in cybersecurity is that hackers no longer have to target someone individually. Instead, they may buy the data of the infected users on dark web markets and exploit them using some of the aforementioned sophisticated tools [33]. For instance, a hacker can look up the URL of the targeted enterprise and see if any of its users have been infected. If so, the hacker may proceed and buy all the data from such a user, including not only the enterprise URL credentials but all the other data from the compromised device, such as the enterprise’s Virtual Private Network (VPN) credentials, session cookies, other application information, and detailed device and network information. Such an approach may render many conventional defense strategies useless, allowing the hackers to bypass user authentication methods and gain access to VPNs, chats, storage, source code, and other sensitive data. Our analysis aims to identify such threats systematically, mapping them to specific components and interactions within the IDS, thus complementing the existing criteria to form a more robust security framework in both the short term and the long term. To achieve this goal, we must choose an adequate methodology and perform threat modeling.

2.2. Threat Identification

A threat is a potential undesirable event or action that may have negative consequences for the system, business, or individual. Threat modeling is a set of activities for enhancing security by identifying threats and determining countermeasures to reduce the likelihood of their occurrence or mitigate their impact on the system. It involves analyzing the system from the perspective of potential attackers, mapping out what they might target and how. To conduct threat modeling, we opted for STRIDE [34] as the best tool for our task. It is a threat modeling methodology developed by Microsoft [35] in 1999 to identify and categorize six specific types of security threats: spoofing, tampering, repudiation, information disclosure, DoS, and elevation of privilege. A more detailed description of the types of categorized threats is shown in

Table 2. STRIDE threat model elements.

Threat	Description	Security Property Violated
Spoofing	Impersonating a user or system component to gain unauthorized access.	Authentication
Tampering	Unauthorized alteration of data or code.	Integrity
Repudiation	Performing actions that cannot be traced back to the perpetrator.	Non-repudiation
Information Disclosure	Unauthorized access to confidential or sensitive information.	Confidentiality
Denial of Service	Disrupting or denying valid users access to services or resources.	Availability
Elevation of Privilege	Gaining unauthorized access to higher-level permissions or functions.	Authorization

. STRIDE’s strengths lie in its broad applicability and comprehensive threat coverage, although it can be time-intensive and requires expert knowledge. STRIDE is a straightforward and easy-to-understand approach consisting of three main steps: identification of the architecture, breaking into components or trust boundaries (TBs) encompassing multiple components, and identifying threats to each component or TB. Therefore, STRIDE can be conducted for each component individually or for each TB, including various components of the same trust level. In our paper, we analyze each TB because otherwise, there would be duplicates in the results for components of the same trust level. While various other security assessment methodologies exist, such as LINDDUN for privacy threats, OCTAVE for risk management or business-centric PASTA, STRIDE is more general and hence most suitable for our analysis as the discussed threats are also general, affecting a broad range of systems. Considering that the IDS is still in the development stage, we find the STRIDE methodology sufficient. Other, more complex threat identification methodologies take more factors into consideration and would not be utilized to their full extent because the system is not even fully operational yet. STRIDE is a simple method for answering the question: “What can go wrong in the system?” It is also the most mature and well-established threat identification methodology that is often used as a baseline for comparison against others. By focusing on the risks inherent in authentication, data exchange, and distributed TBs, STRIDE allows us to systematically address security concerns in a multifaceted system like the IDS testbed, ensuring that all relevant threats are considered early in the design process.

In summary, while IDS and similar systems provide the means for secure data sharing, significant gaps remain in addressing threats like endpoint security, MitM and DDoS attacks, and backdoors. Given that the IDS framework is still in development, now is the ideal time to assess and address these vulnerabilities. Our work aims to identify threats systematically and proposes solutions that can be integrated into the IDS framework, thereby contributing to a more secure and resilient data space architecture.

3. Methodology

STRIDE is a widely adopted threat modeling framework that helps identify potential security threats by categorizing them into six distinct types. Threat modeling allows for identifying, understanding, preventing, and mitigating threats. STRIDE, in particular, is an easily applicable methodology requiring the security auditor to define TBs and examine what could possibly go wrong at each TB while considering the six threat categories from Table 2. This systematic approach suits complex systems such as IDS, where many components with different roles and privileges interact. To conduct the STRIDE-based threat analysis, we followed the guidelines provided by the Open Worldwide Application Security Project (OWASP) [34] and the United Kingdom’s Department for Science, Innovation, and Technology [36]. We applied the STRIDE framework to the IDS by conducting the following:

1.

System decomposition: Dismantling the IDS architecture into its core components, forming a context diagram that shows how data flows through the application.

2.

TB enumeration: Marking the places in the context diagram where trust levels change. A single TB will surround all components with the same security attributes.

3.

Threat enumeration: Systematically identifying potential threats for each STRIDE category at each TB.

4.

Risk assessment: Incorporating real-world practical scenarios involving known hacking tools and techniques to illustrate how threats could manifest.

5.

Mitigation: Provide mitigation strategies.

Since the IDS testbed is still in the early development stages, now is the right time to perform the security assessment. This way, it will be easier to consider security concerns, as doing so in the later development stages requires more effort. However, even in the early stages, the project is relatively big, consisting of 13 Docker containers. Given the size of the project, we chose not to develop detailed Level-1 and Level-2 data flow diagrams. Instead, we conducted the STRIDE analysis on the context diagram of the final envisioned version of the testbed made by IDSA (Figure 1), as it provides a simplified system overview. A context diagram, also known as a Level-0 diagram, is the most basic form of a data flow diagram that provides a high-level visualization of interrelationships between the system and external components without getting into the internal processes. Moreover, since some of the IDS components are incomplete, it does not make sense to examine the details yet. Instead, we performed threat modeling manually on the proposed architecture, relying on documentation and architectural descriptions rather than empirical data or simulations because they are unavailable since the system is not fully operational yet. Despite its high-level nature, this approach helps to establish the foundations for the system’s early security posture. We present the description of the TBs in

Table 3. TBs in IDS testbed for STRIDE analysis.

TB	Description
TB 1: Testing Backend	Isolates the testing suite from the operational components, ensuring that any vulnerabilities or errors in the testing environment do not compromise the live system.
TB 2: Endpoints and Connectors	Encloses data providers, consumers, brokers, and testing agents. This boundary ensures that interactions between various endpoints and the system are secure and do not affect the core infrastructure.
TB 3: Clearing House and ParIS	Encloses the infrastructure elements responsible for logging and participant information. These components handle sensitive information and are isolated from the rest of the data exchange and operational components.
TB 4: CA	Isolates the CA to ensure the security of certificate issuance, management, and validation processes, keeping them separate from the data exchange infrastructure.
TB 5: DAPS	Separates the DAPS to secure the management of dynamic identity attributes and tokens, keeping these processes independent of the main data exchange and operational components.

to provide a more detailed insight into the reasoning behind the choice of positioning the boundaries as displayed in the context diagram (Figure 1).

The system includes a central Connector Under Test (CUT), the main component being evaluated for secure data exchange functionality within the IDS framework. The CUT interacts with multiple components, such as a Clearing House, Participant Information Service (ParIS), Broker, and Dynamic Attribute Provisioning Service (DAPS). The testing backend configures, triggers, and monitors the operations of the various test agents, generating reports on the CUT’s performance. Connector agents provide and request data, emulating a real-world data exchange. The CUT facilitates data transfer between these connectors, ensuring compliance with IDS policies and security protocols. The broker registers and queries available data sets, while the Clearing House logs details of data exchanges, maintaining transparency and traceability. The Certificate Authority (CA) issues and manages certificates, verifying the identity and integrity of connectors. The Online Certificate Status Protocol (OCSP) is a protocol for checking the revocation status of an X.509 digital certificate in real time. DAPS provides and verifies dynamic attributes, ensuring that only authorized entities access the data. It is worth mentioning that the system’s designed interface is web-based.

As part of the STRIDE analysis, we construct a table of identified strengths and vulnerabilities for each STRIDE threat type at every TB. We assess strengths and weaknesses based on the recommendations for threat modeling and previously discussed threats. Upon identifying threats, we enumerate them to ensure that each can be independently addressed. The process of applying the STRIDE methodology to the IDS is described in Algorithm 1. This process is typically conducted manually by a cybersecurity analyst who takes many factors into consideration, requiring critical thinking, expertise, and judgment to translate high-level guidelines into actionable threat insights and appropriate countermeasures.

Algorithm 1 STRIDE-based threat analysis with category-specific strength assessment.

1: Input: ContextDiagram, Components, KnownThreats, SecurityMeasures   2: Output: REPORT   3: // Identify data flows between components from the context diagram   4: $DATA\_FLOWS\leftarrow IdentifyDataFlows(ContextDiagram,Components)$   5: // Determine trust boundaries by examining how data flows connect   6: // components that differ in trust levels, roles, and security assumptions.   7: $TRUST\_BOUNDARIES\leftarrow DetermineTrustBoundaries(ContextDiagram,$   8:        $Components,DATA\_FLOWS)$   9: $STRIDE\_CATEGORIES\leftarrow \{SPOOFING,TAMPERING,REPUDIATION,$ 10:      $INFORMATION\_DISCLOSURE,DENIAL\_OF\_SERVICE,$ 11:      $ELEVATION\_OF\_PRIVILEGE\}$ 12: $VULNERABILITIES\leftarrow \varnothing$ 13: for all $TB\in TRUST\_BOUNDARIES$ do 14:  // Extract only flows relevant to this TB 15:  $RELEVANT\_DATA\leftarrow FilterFlows(DATA\_FLOWS,TB)$ 16:  for all $CATEGORY\in STRIDE\_CATEGORIES$ do 17:    $STRENGTHS\leftarrow IdentifyStrengthsForCategory(CATEGORY,TB,$ 18:           $RELEVANT\_DATA,SecurityMeasures)$ 19:    $ISSUES\leftarrow IdentifyPotentialIssues(CATEGORY,TB,RELEVANT\_DATA)$ 20:    // Integrate known, documented threats for this category and TB 21:    $ISSUES\leftarrow ISSUES\cup IdentifyKnownThreats(CATEGORY,TB,$ 22:           $RELEVANT\_DATA,KnownThreats)$ 23:    for all $ISSUE\in ISSUES$ do 24:    if $AssessFeasibility(ISSUE,TB,SecurityMeasures,STRENGTHS)=HIGH$    then 25:       $NEW\_VULN\leftarrow CreateVulnerability(ISSUE,TB,CATEGORY)$ 26:       $VULNERABILITIES\leftarrow VULNERABILITIES\cup \{NEW\_VULN\}$ 27: $REPORT\leftarrow GenerateReport\left(VULNERABILITIES\right)$ 28: for all $VULN\in VULNERABILITIES$ do 29:   $M\leftarrow SuggestMitigations(VULN,SecurityMeasures)$ 30:   AddMitigationsToReport(REPORT, VULN, M) 31: return REPORT

4. Results

In this section, we present the results of the STRIDE analysis performed on the final envisioned version of the IDS testbed and provide mitigation strategies. We conducted the STRIDE analysis for each TB and enumerated the potential vulnerabilities. The results of the STRIDE analysis are presented in

Table 4. STRIDE analysis for TB 1: Testing backend.

STRIDE Category	Strengths	Weaknesses
Spoofing	Isolation of the testing backend limits impersonation.	None.
Tampering	Encrypted communication via TLS protects data integrity during transmission.	v01: Possible backdoors in open-source tools may allow tampering.
Repudiation	Logging mechanisms track operations and can provide non-repudiation.	None.
Information Disclosure	TLS and secure certificates provide confidentiality for data in transit. Encryption of sensitive data prevents unauthorized access.	v02: Compromised end-user devices may expose sensitive data.
Denial of Service	None.	None.
Elevation of Privilege	Role-Based Access Control (RBAC) enforces proper privilege.	None.

,

Table 5. STRIDE analysis for TB 2: Endpoints and connectors.

STRIDE Category	Strengths	Weaknesses
Spoofing	Client certificate verification limits spoofing.	v03: SIM swapping can bypass Multi-Factor Authentication (MFA) in many places and allow access to potentially sensitive information. v04: Compromised end-user devices (credentials and session cookies) can allow hackers to bypass MFA. v05: MitM attacks allow for session hijacking.
Tampering	Encrypted communication via TLS protects data integrity during transmission.	v06: Possible backdoors in open-source tools may allow tampering.
Repudiation	Logging mechanisms track operations and can provide non-repudiation.	None.
Information Disclosure	TLS and secure certificates provide confidentiality for data in transit. Encryption of sensitive data prevents unauthorized access to information.	v07: Compromised end-user devices may expose sensitive data.
Denial of Service	None.	v08: DDoS attacks may target the system’s access points.
Elevation of Privilege	RBAC enforces proper privilege.	None.

,

Table 6. STRIDE analysis for TB 3: Clearing house and ParIS.

STRIDE Category	Strengths	Weaknesses
Spoofing	X.509 certificate authentication for all entities interacting with the system.	None.
Tampering	Encrypted communication via TLS protects data integrity during transmission. Encrypted storage ensures data integrity.	v09: Backdoors in open-source software could allow tampering. v10: Key mismanagement.
Repudiation	Logging mechanisms track operations and can provide non-repudiation.	None.
Information Disclosure	TLS and secure certificates provide confidentiality for data in transit. Encryption of sensitive data prevents unauthorized access to information.	v11: Key mismanagement can lead to the exposure of encrypted information.
Denial of Service	Separation of entities limits the damage of DDoS attacks.	v12: DDoS attacks may disable the service, allowing repudiation in the system.
Elevation of Privilege	RBAC enforces proper privilege.	None.

,

Table 7. STRIDE analysis for TB 4: CA and OCSP.

STRIDE Category	Strengths	Weaknesses
Spoofing	Public Key Infrastructure limits spoofing.	None
Tampering	CA only handles encrypted certificates, limiting information disclosure.	None.
Repudiation	Detailed logging of certificate issuance processes.	None.
Information Disclosure	Encryption of certificate storage and transmission.	v13: Mismanaged keys can expose sensitive certificate information.
Denial of Service	None.	v14: DoS attacks targeting the CA can block certificate services.
Elevation of Privilege	Privileged access is limited to a few authorized personnel.	v15: Compromised end-user devices v16: MitM attacks may allow hackers to gain privileged access. v17: SIM-swapping may allow hackers to gain privileged access.

and

Table 8. STRIDE analysis for TB 5: DAPS.

STRIDE Category	Strengths	Weaknesses
Spoofing	Mutual authentication with X.509 certificates.	None.
Tampering	Token signing protects data from tampering.	None.
Repudiation	DAPS logs all token-related activities.	None.
Information Disclosure	Encrypted transmission of tokens.	v18: Key mismanagement can lead to the exposure of encrypted information.
Denial of Service	None.	v19: DAPS may be targeted to disable token provisioning in DDoS attacks.
Elevation of Privilege	Privileged access is limited to a few authorized personnel.	v20: Compromised end-user devices v21: MitM attacks. v22: SIM-swapping may allow hackers to gain privileged access.

. The vulnerabilities are enumerated in ascending order using the vxx syntax, where xx is a two-digit number starting from 01.

The results of our analysis confirm that novel threats such as compromised end-user devices, backdoors in open-source software, MiTM attacks, and SIM swapping pose significant security challenges to the IDS framework. Traditional vulnerabilities such as weak key management and susceptibility to DDoS attacks were also identified across multiple TBs. Most of the threats were identified individually at TB 2, where we enumerated eight vulnerabilities. This result is intuitively clear, as TB 2 is the critical interface between users (public Internet) and the IDS, exposing it to external attack vectors. This exposure increases the likelihood of exploitation, primarily via compromised user devices and network-based threats such as MitM and DDoS attacks. TB 2’s vital role in handling sensitive interactions between external endpoints and the system underscores its heightened risk profile. In contrast, other TBs such as TB 1, TB 3, TB 4, and TB 5, which are responsible for secure internal operations, certificate management, and token provisioning, show fewer vulnerabilities but remain susceptible to targeted attacks, mainly if key management processes are not rigorously followed or if internal services like the CA are overwhelmed by DoS attacks. The analysis highlights several threats, particularly at TB 2, where the attack surface is the largest and the potential impact of vulnerabilities is most significant. Additionally, we present an attack tree example (Figure 2) to illustrate the spoofing threat analysis of TB 2. An attack tree is a hierarchical diagram that models potential attack paths, starting from a high-level goal (root node) and breaking it down into sub-goals (branches) to analyze threats systematically. Although SIM swapping may not directly allow for the reissuing of a certificate, it may allow resetting passwords and gaining access to many online services where the users may also store X.509 certificates, such as emails, chats, and cloud storage. While the certificate is necessary for authentication, session cookies are sufficient for maintaining the session and thus pose a security risk if compromised. Similarly, root access to the system can allow the hackers to easily modify or issue new login credentials to themselves and pass the authentication phase effortlessly.

Lastly, in

Table 9. Vulnerabilities and mitigation strategies.

Vulnerability	Mitigation Strategy
v01, v06, v09: Backdoors in open-source tools (TB 1, TB 2, TB 3)	Conduct thorough code audits, secure coding practice, and integrate automated vulnerability scanning tools for open-source components. Establish strict dependency management and verify the integrity of third-party software components.
v02, v04, v07, v20: Compromised end-user devices exposing sensitive data or bypassing authentication (TB 1, TB 2, TB 5)	Implement Endpoint Detection and Response (EDR) systems, enforce app-based MFA or hardware tokens (instead of SMS-based), and apply strong encryption for both stored and transmitted data. Set appropriate session cookie expiry times (e.g., 8 h to require a single login at the beginning of each work shift). Enforce using separate devices for work. Regularly update and patch user devices to minimize exposure to vulnerabilities.
v03, v17, v22: SIM swapping allowing unauthorized access (TB 2, TB 4, TB 5)	Monitor mobile accounts for unusual activities and enforce strict identity verification before number porting (if the company has that ability). SIM-swappers commonly rely on social engineering via phone calls to achieve number porting. Hence, the process should require knowledge of details that hackers cannot easily obtain. Avoid purely SMS-based MFA and password resetting.
v05, v16, v21: MitM attacks enabling session hijacking or privilege escalation (TB 2, TB 4, TB 5)	Use mutual TLS authentication, certificate pinning, and regularly rotate encryption keys and certificates. Deploy intrusion detection systems to detect suspicious activities indicative of MitM attacks. Set appropriate session cookie expiry times (e.g., 8 h to require a single login at the beginning of each work shift).
v08, v12, v14, v19: DDoS attacks targeting system access points and services (TB 2, TB 3, TB 4, TB 5)	Implement DDoS protection mechanisms like rate limiting, traffic filtering, and load balancing. Use redundant systems and failover strategies to maintain service availability during attacks. Use IP whitelists to only allow access to the trusted users.
v10, v11, v13, v18: Key mismanagement leading to exposure of sensitive data or encrypted information (TB 3, TB 4, TB 5)	Establish robust key management practices, including secure storage, regular key rotation, and strict access controls. Automate certificate issuance and revocation processes to reduce the risk of expired or compromised keys being used.

, we provide mitigation strategies for the identified vulnerabilities. In addition to technical solutions, regular and comprehensive security training for IDS users should also be incorporated. Some of the discussed threats are unknown to the average users, making them the weakest link in the security chain. Security training should focus on raising awareness about risks such as SIM swapping, compromised end-user devices, and MitM attacks, as well as best practices for handling sensitive data and recognizing suspicious activities. Training should also cover how to respond to security incidents, such as reporting suspicious behavior or device compromise. By educating users, organizations can significantly reduce the likelihood of successful attacks that target human vulnerabilities.

5. Discussion

The STRIDE analysis identified several persistent vulnerabilities across the IDS in the wake of newly appearing attack vectors. TB 2 was recognized as the most risky due to its exposure to the public Internet. Data from compromised end-user devices may end up on dark web markets, where they can be subsequently bought and exploited via tools such as Linken Sphere. This vulnerability may pose an even more significant threat to enterprise software, as user data may allow hackers to cause more damage. For instance, stolen session cookies can be used to access the enterprise website, data, source code, etc., allowing the hackers to steal or tamper with the data. Furthermore, end-user devices can also be victims of MitM attacks, resulting in hijacked user credentials and session cookies. While SIM swapping may seem like a minor threat affecting SMS-only services, it is far from harmless. Many digital service providers rely on phone numbers to reset passwords and gain access to their services. These include email providers, social media, and chat applications that may harbor useful information for hackers. Lastly, sophisticated attacks originate from backdoors in open-source projects that may happen to be some of the most prevalent applications, as shown in recent examples. Such backdoors pose a significant challenge because building applications from scratch requires many resources, whereas including the existing software takes much less time and effort. Therefore, if the utilized software is compromised, it can easily lead to the most severe consequences. Detecting malicious code in such software is difficult due to obfuscated code [37], external dependencies, etc. In our case, we assumed that the application developers did not have malicious intent and were not compromised, which may not always be the case. In summary, we identified numerous threats to the IDS, confirming that, according to its current plan, it will be susceptible to multiple severe threats once operational.

Several identified vulnerabilities directly threaten regulatory compliance. For example, compromised endpoints (e.g., via MitM attacks) can expose personal data to unauthorized parties, risking non-compliance with GDPR’s confidentiality requirements. Similarly, unauthorized data extraction through backdoors or service disruption via DDoS attacks can undermine the operational resilience expected under the NIS2 directive. By addressing these vulnerabilities, the IDS can better align with both GDPR and NIS2.

The IDS already incorporates industry-standard security mechanisms, such as X.509 certificates, TLS protection, and RBAC. However, some mechanisms, such as protection against DDoS attacks via redundancy, can be improved, as proposed in Mahiru [24]. In the context of mitigation strategies, it is necessary to consider the effectiveness, feasibility, and financial costs arising from the additional security measures. While scalable solutions for DDoS defense exist in the form of network packet filtering and system redundancy, they may significantly increase operational costs. For instance, Cloudflare’s latest report for the third quarter of 2024 shows they were able to mitigate over 6 million DDoS attacks, some of which had an intensity of over 4 Tbps [38]. Such an attack would devastate most, if not all, of the unprotected systems, thus proving that DDoS defense is a valuable investment. Hence, an intrusion detection system that performs packet filtering should always protect the system’s endpoints. A commonly applied security solution for enterprise business is IP whitelisting, where only a set of trusted IP addresses can access the system. The effectiveness of IP whitelists based on trust metrics, such as previous successful logins showing nearly impeccable performance, was demonstrated by Yoon [39]. Since IDS is an enterprise software, removing it entirely from the public Internet and allowing access to only a set of whitelisted IP addresses would significantly reduce the risk of DDoS and other attack vectors. This approach is commonly applied to a set of static IP addresses, typically belonging to a VPN, so that the users have to connect using a VPN whose IP is trusted by the IDS. The attackers would have to compromise the user’s VPN credentials before becoming able to attack the system. Therefore, this approach would add an additional layer of protection without any considerable trade-offs. In addition to server protection, external security providers can also outsource user device protection. Such protection is achievable via EDR, which, in combination with ML, constitutes a formidable proactive defense approach [40]. Adopting a semantic approach to designing authentication components, as proposed by Zhidovich et al. [41], can improve the efficiency and compatibility of security mechanisms within the IDS. This approach emphasizes the integration of standardized, secure authentication protocols, enhancing resistance to threats such as phishing and MitM attacks. In terms of source code security, achieving absolute sovereignty over code is not something that most companies can afford, so remedies such as code auditing, automated software review tools, and secure coding practices are recommended. For example, Bhandari et al. [42] provides an ML-based source code analyzer that successfully scans the code for vulnerabilities. Finally, the system should undergo regular security assessments to keep up with the state-of-the-art threats and protection.

Nevertheless, another essential aspect that should be considered is the human factor, as the system users will interact with TB 2 the most. The human factor can be the deciding element in the success of device compromise and MitM attacks. Therefore, implementing and enforcing security policies and frequent security training sessions with the users is essential. Equally important is ensuring responsible and ethical handling of any data the system processes. Administrators and authorized personnel must adhere to strict policies and oversight mechanisms to prevent data misuse or unauthorized disclosure, thus maintaining trust and aligning with ethical standards and regulatory requirements. Judging by recent events, it appears that security incidents involving sophisticated viruses that compromise end-user devices and MitM attacks are on the rise as cyber-criminal strategies evolve and become accessible to a large number of hackers. Dark web markets present a service-oriented criminal economy where hackers no longer have to conduct the entire hacking process independently. They may instead outsource processes such as user data acquisition, setting up proxies and VPNs, creating hacking tools, and others. Instead, these and many others are now available for purchase as data, software, and services.

In our study, we used the final envisioned version of the IDS testbed as a reference. However, as the system evolves, there may be changes to how it is implemented, but new threats may also appear in due time. Although our analysis is comprehensive, it is still limited to the available resources, and it was conducted on a high level using a context diagram. Once the software is of higher technical readiness, the analysis should be repeated using more detailed data flow diagrams. Such an approach will provide a far more detailed insight into every aspect of the system and will result in a more comprehensive security analysis. Our study was limited to threat modeling and did not include a risk assessment. Threat modeling, as performed using the STRIDE methodology, is a foundational step in identifying potential security issues. We systematically enumerated possible vulnerabilities and attack vectors without assigning them probabilities or impacts. Since the IDS is still in its conceptual and developmental phases, many parameters required for a meaningful risk assessment are missing. For instance, actual deployment environments, user interaction patterns, and system reliability metrics are not available yet. Without this contextual information, any attempt at quantitative risk assessment would be speculative and potentially misleading. By clearly understanding where and how threats may emerge, we create a basis for future risk evaluations to build once the system is more mature, tested, and closer to a production environment. Therefore, threat modeling is best viewed as a prerequisite step that informs and refines subsequent risk assessments, ensuring that when risk analysis is conducted, it is grounded in realistic operational data and meaningful context. In the future, we plan to research concrete tools for preventing, detecting, and mitigating the discussed threats, thus contributing to safer enterprises.

6. Conclusions

In this study, we analyzed the IDS and performed a STRIDE threat analysis on the final envisioned version of the IDS testbed. Our study was the first to perform threat analysis on the IDS and, hence, to evaluate how novel threats would affect it. We presented some of the most impactful state-of-the-art hacking tools and techniques that have already caused havoc to large corporations and integrated them into our analysis. Using the context diagram provided by the IDSA, we identified five TBs and conducted the STRIDE analysis for each. The results indicate that the highest number of threats exist at the TB between end-users and the IDS system. We highlighted both technical aspects and the importance of the human factor in cybersecurity. Lastly, we proposed a set of mitigation strategies and discussed potential system improvements. This study lays the foundation for further threat analysis of the IDS and should aid researchers and industry in developing a more robust and secure data spaces framework.