Threat Modeling for Security and Privacy in a Corporate Ecosystem Integrating Cloud-Based CRM and AI Analytics

1. Introduction

The growing adoption of cloud platforms dedicated to data management, analytics, and Artificial Intelligence (AI) has transformed the way organizations structure decision-making processes, automate operational workflows, and expand their capacity to process large volumes of data [1,2]. At the same time, cloud-based customer relationship management (CRM) platforms have come to occupy a strategic position in this scenario by centralizing interactions, histories, and transactional data that support commercial and analytical actions, yielding significant gains in scalability, flexibility, and reduced operational costs [3,4]. When organizations integrate these two domains into a single digital ecosystem, this integration simultaneously expands operational benefits and the attack surface, thereby increasing the complexity of information protection requirements [5].

In this context, the convergence between cloud-based CRM and AI services introduces threats that extend beyond the traditional information security perspective. When associated with probability and impact estimates, these threats configure risks that demand systematic treatment within information security management [6]. Recent estimates indicate that 82% of data breaches involve information stored in the cloud, a scenario aggravated by the centralization of sensitive data and the intensive use of digital integrations [7]. Moreover, AI platforms remain subject to specific compromise vectors, such as inadvertent information leakage through prompts and unintentional memorization of training data, which impose additional risks to confidentiality and to data lifecycle governance [8,9]. The exposure amplified by APIs, when robust authentication, granular access control, and traffic validation do not protect it, represents another critical exploitation vector [10,11].

Equally relevant privacy and regulatory compliance concerns compound this security dimension. Legislation such as the General Data Protection Regulation (GDPR) and Brazil’s General Data Protection Law (LGPD) require transparency, data minimization, and rigorous protection controls, while the incorporation of AI into CRMs expands risks such as model manipulation, integration misuse, and automated data exfiltration [9,12]. In addition, ethical concerns related to algorithmic bias and potential manipulation of automated decisions have emerged, making the development of more transparent and accountable models indispensable [5,13].

Given this context, threat modeling proves especially relevant because it allows researchers to examine the system in a structured manner from its architectural conception, favoring early identification of vulnerabilities and the timely adoption of mitigation measures before risk analysis becomes limited to responding to incidents that have already occurred [6,14,15].

In this scenario, the combination of cloud-based CRM platforms, AI-driven analytics services, and intensive API-based integrations concentrates large volumes of personal and corporate data within tightly coupled ecosystems, amplifying the potential impact of security and privacy failures, including data breaches, operational disruptions, and regulatory non-compliance.

Building on this perspective, this paper investigates this specific ecosystem and proposes security and privacy controls for a corporate environment that integrates cloud-based CRM with AI analytics services. We use threat modeling as the central methodological approach, operationalized through Data Flow Diagrams (DFDs) and the STRIDE and LINDDUN frameworks, to identify and classify threats across the security and privacy dimensions, and map them to NIST SP 800-53 Rev. 5 controls. This study's contribution is threefold: it applies the combined chain to a real production architecture rather than a synthetic or hypothetical system; it validates threat prioritization through a Delphi-inspired panel of nine security experts; and it preserves full traceability from individual data flows to specific normative control codes. To the best of our knowledge, this full chain, spanning architectural modeling, dual security-privacy classification, expert validation, and normative control mapping, has not been reported together in the threat-modeling literature for CRM and AI analytics ecosystems.

Beyond this introduction, Section 2 discusses the theoretical framework; Section 3 presents related work; Section 4 describes the methodology adopted; Section 5 presents and discusses the results; and Section 6 draws the conclusions of this study.

2. Theoretical Background

2.1. Cloud Data, Analytics, and AI Platforms

Cloud data, analytics, and AI platforms represent a strategic approach to managing and exploring data within organizations, combining cloud infrastructure, big data, and AI to enable scalable processing and evidence-based decision-making. Thomas [1] emphasizes real-time insight generation, while Kumar [2] and Rahul [16] highlight the cloud as a pillar for distributed storage and data integration.

Kumar [2] and Yang et al. [17] identify cloud-based big data analysis as key to detecting patterns in complex scenarios. Kadakia [18] and Priyadarshi [19], by contrast, emphasize AI as a mechanism for automation and analytical optimization, addressing not only volume but also efficiency through learning algorithms and predictions. These findings show that although the authors converge on the general theme, some prioritize scale and integration while others emphasize the algorithmic layer.

Among the benefits, Kumar [2] and Rahul [16] highlight scalability and cost efficiency. Rahul [16] and Piastou [20] note that AI-driven automation reduces operational costs, while Priyadarshi [19] emphasizes improved decision-making through real-time analysis. These findings suggest that the gains provided by these platforms extend to organizational agility and precision.

Kadakia [18] and Priyadarshi [19] highlight governance and data quality issues related to AI, echoing the concerns of Priyadarshi [19] about information silos and ethical questions; this dialogue suggests that greater analytical capacity introduces tensions in governance and accountability.

These studies converge in recognizing these platforms as strategic to business operations, but they diverge regarding operational benefits, governance, and ethics. This diversity matters to the present study because ecosystems such as cloud-based CRM with AI operate under simultaneous pressures of performance, cost, and compliance, reinforcing the need for threat modeling that considers not only the technical surface but also data quality, governance, and ethics.

2.2. Cloud-Based Customer Relationship Management Platforms

Structurally, cloud-based CRM platforms rely on multi-layer architectures (cloud infrastructure, data, applications, and interface layers), which favors customization and interoperability with other corporate solutions [21].

Verravalli [22] highlights that AI expands CRM capabilities through automation, predictive analytics, and natural language processing. Kattula [23] adds that integration with IoT and blockchain extends analytical capacity and operational reliability. Together, these studies indicate that cloud CRM has evolved from a record-keeping tool into an analytical and strategic convergence point among customer data, sensors, and intelligent services.

Regarding benefits, Sharma et al. [3] show that dynamic resource allocation reduces costs and facilitates demand-based scaling. Rajurkar [24] highlights that a unified view of customer data enables greater personalization and loyalty, while Verravalli [22] stresses productivity gains through automation; together, these contributions articulate technical efficiency, customer experience, and economic advantages.

In terms of applications, cloud CRM supports patient engagement in healthcare (with a focus on regulatory compliance), personalization in retail, and resource optimization in agriculture through IoT and predictive analytics [23], evidencing its role as an integrating element in contexts sensitive to security and business continuity.

Bethi [25] identifies challenges such as data privacy, integration with legacy systems, and the need for constant updates, showing that the success of cloud CRM also depends on governance and strategic planning. For this study, these findings reinforce the conclusion that CRM architectures integrated with AI analytics expand the attack surface, thereby justifying structured threat modeling approaches.

2.3. Data Flow Diagrams

Data Flow Diagrams (DFDs) are a useful tool for system analysis and design because they graphically represent the flow of data, processes, and entities, thereby facilitating communication among stakeholders [26]. Schmalenberg and Vandenhouten [27] highlight that their organization into levels of abstraction supports the documentation of modular solutions and the identification of weaknesses in complex architectures.

Afyenni [28] and Haviluddin [29] describe the classic DFD structure as comprising four elements: entities, processes, data stores, and data flows. This structure converges with threat modeling approaches such as STRIDE and LINDDUN, which operate on these same components.

Regarding applications, Zhang et al. [30] discuss the use of DFDs in software engineering, while Reawaruw et al. [31] highlight their organizational use in small businesses for process improvement. Chiş et al. [32] explore their role in cybersecurity for identifying vulnerabilities in data flows, evidencing an evolution from a descriptive to an analytical security function.

In the academic field, Tundo and Saidah [33] highlight DFDs as a didactic resource for teaching systems design, a view that converges with Syahputra et al. [34], who argue that these diagrams promote clarity and communication between technical and non-technical audiences.

Among the benefits, the literature stresses the structured approach to analysis and design, which allows researchers to consider components and dependencies systematically [35]. Fahmi and Sutaji [36] add that representation at different levels of detail enables a gradual view of the architecture. For this study, this characteristic proves relevant because it allows us to model ecosystems such as cloud CRM and AI analytics, revealing data flows and trust boundaries that will serve as the basis for threat modeling with STRIDE and LINDDUN.

2.4. Threat Modeling

Yokoyama and Arima [37] and Shostack [6] present threat modeling as a systematic technique for identifying risks during the conception and design phases, thereby reducing the cost of late-stage corrections. This view aligns with the Threat Modeling Manifesto, which holds that the best use of threat modeling improves security and privacy through early and frequent analysis [14].

Shostack [6] synthesizes the process into four questions, namely “What are we working on?”, “What can go wrong?”, “What are we going to do about it?”, and “Did we do a good job?”, forming an iterative structure that has gained wide adoption. Cerqueira Junior and Arima [38] relate this framework to IT risk management.

Shostack [6] distinguishes three approaches: attacker-centered, system/software-centered, and asset-centered. Schneier [39] illustrates the first by focusing on adversary motivations and capabilities, whereas Nweke and Wolthusen [40] exemplify the second by prioritizing protection according to asset criticality.

The software-centered approach analyzes components, data flows, and trust boundaries to identify design flaws. Although these approaches remain distinct, researchers can combine them to obtain a more comprehensive view [6]. For cloud systems that process high-value data, Shostack [6], Nweke and Wolthusen [40], and Braiterman et al. [14] recommend starting with software-centered approaches and DFDs. This orientation aligns with the methodology of this study.

On the security axis, traditional approaches (Security Threat Analysis, STA) tend to derive privacy from confidentiality, integrity, and availability rather than treating it as an autonomous requirement. Robles-González, Parra-Arnau, and Forné [41] criticize this limitation and highlight privacy threat analysis (PTA) frameworks, such as LINDDUN, which cover specific categories (linkability, identifiability, non-compliance) that conventional frameworks do not capture.

The combination of security and privacy frameworks applied to the same DFD representation, therefore, configures a dual and complementary approach. Deng et al. [42], Wuyts and Joosen [43], and Robles-González et al. [41] explore this synergy by integrating STRIDE and LINDDUN in cloud-based personal data systems. This study joins this line of research by applying this combination to a cloud CRM and AI analytics ecosystem, using DFDs as a common basis for classifying threats in a traceable manner.

2.5. STRIDE Framework

Researchers present STRIDE as a cybersecurity risk analysis methodology developed by Loren Kohnfelder and Praerit Garg in 1999, which Microsoft later incorporated into its Security Development Lifecycle (SDL), establishing it as one of the most widely disseminated threat modeling frameworks [44,45]. Unlike asset-centered approaches such as EBIOS, STRIDE departs from security properties (confidentiality, integrity, availability, authenticity, non-repudiation, and authorization), organizing attacks that violate each of them [44,46].

The adoption of STRIDE within the SDL institutionalized threat modeling as a mandatory practice from the specification and architecture phases onward [44,47]. Ouaissa and Ouaissa [46] reinforce the idea that applying STRIDE in the early phases enables proactive vulnerability mitigation and less costly corrections.

The acronym groups six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege [44,48]. These categories correspond to the properties of authenticity, integrity, non-repudiation, confidentiality, availability, and authorization, respectively. Spoofing involves the misuse of credentials; Tampering involves the unauthorized alteration of data or code; and Repudiation results from the absence of audit and traceability mechanisms [45,47].

Information Disclosure involves the leakage of sensitive data, Denial of Service compromises availability, and Elevation of Privilege occurs when agents execute unauthorized actions [45,48,49]. The authors converge in their description of these categories but vary in the practical cloud-based examples and the formalization of security properties they employ.

This study focuses on the articulation between STRIDE and DFDs. Knight [50] systematizes the relationship between the six categories and the four DFD elements (entities, flows, stores, and processes), proposing a per-element approach that indicates which threats apply to each component. Table 1 presents this relationship, which serves as the reference for threat classification in this study.

Based on this mapping, the per-element analysis adopted in this study involves examining each DFD element of the corporate ecosystem (external entities, flows, stores, and processes) to identify which STRIDE categories apply and how they manifest in the specific context of integrating cloud CRM and AI analytics services. This articulation between the STRIDE threat catalog and the DFD structure enables researchers to conduct threat modeling in integrated corporate environments systematically and in a traceable manner, aligning with the system-centered recommendations discussed in the threat modeling section.

2.6. LINDDUN Framework

Robles-González, Parra-Arnau, and Forné [41] present LINDDUN as the only systematic and scientifically grounded Privacy Threat Analysis (PTA) framework. Deng et al. [42] developed LINDDUN, which differs from Security Threat Analysis (STA) approaches that treat privacy as a byproduct of security properties rather than as an autonomous requirement; this distinction shows that STA alone proves insufficient to capture regulatory risks in systems that process personal data.

The acronym aggregates seven categories: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of Information, Unawareness, and Non-compliance [51,52]. Unlike STRIDE, which departs from security properties, LINDDUN focuses directly on privacy and compliance violations.

The framework uses DFDs as its analytical basis [41]. Van Landuyt and Joosen [52] describe three steps: (i) creating an architectural abstraction via DFD; (ii) eliciting threats using the LINDDUN threat tree catalog; and (iii) prioritizing and documenting the most critical threats. Mollaeefar, Bissoli, and Ranise [53] highlight that this iterative process enables researchers to identify violations in a traceable manner, thereby approximating regulatory compliance practices.

According to Beltrán and Calvo [54], the seven categories cover the following aspects:

• Linkability: the ability to correlate items or records belonging to the same individual without knowing that individual’s identity;
• Identifiability: the ability to identify a subject within a set, a category especially relevant to biometrics and authentication;
• Non-repudiation: the impossibility of denying an action, with a focus on the privacy consequences of that impossibility;
• Detectability: the ability to detect the existence of an item of interest without accessing its content;
• Disclosure of Information: unauthorized access to or use of sensitive data, which constitutes the highest-impact threat;
• Unawareness: the data subject’s lack of knowledge about the purposes and risks of processing their data;
• Non-compliance: failure to comply with legislation, regulation, or organizational policies.

These categories can manifest in a chain, with linkability leading to identifiability and improper disclosure [54], a pattern that is particularly relevant in cloud CRM ecosystems with analytics and AI, where intensive data correlation amplifies privacy risks.

As with STRIDE, Wuyts and Joosen [43] propose a mapping between LINDDUN categories and DFD elements (entities, flows, stores, processes). Table 2 presents this distribution, which serves as the reference for classifying privacy threats in this study.

Based on this mapping, the analysis examines DFD elements to identify LINDDUN categories and to document violation scenarios. The joint application of STRIDE and LINDDUN unifies technical and regulatory risks, grounding threat modeling in corporate cloud environments.

2.7. NIST SP 800-53

NIST [55] developed NIST SP 800-53 Rev. 5 as a comprehensive catalog of security and privacy controls for information systems. It organizes controls into functional families, such as Access Control (AC), Identification and Authentication (IA), System and Communications Protection (SC), and Audit (AU), enabling modular and traceable application [55]. Its adoption remains compatible with frameworks such as the NIST RMF and ISO/IEC 27001 [56,57].

A clear difference in scope separates threat modeling from NIST SP 800-53. While DFD, STRIDE, and LINDDUN identify and classify threats from architectural representations, NIST SP 800-53 offers a catalog of controls to mitigate them. In other words, modeling frameworks answer “What can go wrong?”, whereas NIST answers “Which controls should we implement?”

DFD, STRIDE, and LINDDUN detail the attack surface in specific contexts, such as cloud CRM and AI analytics ecosystems, while NIST SP 800-53 offers a more generic normative repertoire applicable across multiple domains [55,56]. This complementarity indicates that threat modeling helps researchers understand where and how risks arise. At the same time, the NIST catalog guides researchers in selecting which controls to adopt in a manner consistent with recognized standards.

This study therefore positions threat modeling (DFD, STRIDE, and LINDDUN) as the analytical approach for risk identification, and it positions NIST SP 800-53 Rev. 5 as the normative basis for selecting controls aligned with frameworks such as RMF and ISO/IEC 27001 [55,56,57]. This articulation enables researchers to translate prioritized threats into concrete control requirements, strengthening the practical application of threat modeling in organizations pursuing regulatory compliance and security in cloud CRM environments with AI.

3. Related Work

Researchers recognize threat modeling as an essential practice for the secure development of systems because it allows them to identify vulnerabilities during the earliest phases of a project. This practice becomes particularly relevant in cloud environments integrated with artificial intelligence services and CRM platforms, in which architectural complexity and data sensitivity demand the systematic application of frameworks such as STRIDE and LINDDUN.

In the privacy field, Deng et al. [42] propose a pioneering framework for requirements elicitation, demonstrating that structured threat analysis enables researchers to identify vulnerabilities in the collection, processing, and storage of personal data. This contribution established conceptual foundations that influenced the development of LINDDUN and that align with the privacy-by-design principles adopted by regulations such as the GDPR and the LGPD.

Seeking to make this type of analysis more accessible, Wuyts et al. [58] present LINDDUN GO, a simplified version of the framework that reduces its complexity and the time required for application. Their proposal demonstrates that researchers can identify relevant threats in complex systems through learner processes, an important consideration for teams that must reconcile limited resources, operational agility, and data protection. Complementarily, Azam et al. [59], reviewing privacy threat modeling approaches from a GDPR perspective, reinforce the need to incorporate privacy requirements from the architectural conception stage onward, particularly in systems that automatically process large volumes of personal data, such as CRM platforms integrated with analytics and AI.

Within the security domain, Zhang et al. [30] combine STRIDE and DREAD to assess risks in digital data marketplaces and propose a classification system that integrates threats and potential impacts. Their study demonstrates that the combined use of frameworks can improve the quality of analysis in sensitive data-sharing environments. Similarly, Park, Oh, and Lee [60] analyze centralized contact-tracing systems and identify threats such as unauthorized access and information leakage, risks that also apply to corporate CRM platforms that concentrate customer data.

Raciti, Cucurull, and Nadjm-Tehrani [61] develop a soft-privacy threat model for smart vehicles based on STRIDE, employing a methodology designed to identify threats specific to personal data control. The authors show that systematic modeling reveals domain-dependent threats that would not be evident in generic analyses, reinforcing the importance of adapting frameworks to the particularities of each context.

Mirzamohammadi et al. [62] conduct a security and privacy threat analysis for the Solid platform, exploring vulnerabilities in decentralized architectures. Their work discusses access control, authentication, and data protection challenges in environments where multiple services interact through APIs, a scenario analogous to integrated corporate ecosystems. Together, these studies reinforce the need to adapt frameworks to the characteristics of each environment, especially in integrated corporate ecosystems that combine cloud CRM, personal data, analytical services, and artificial intelligence. Unlike this related work, which applies STRIDE or LINDDUN separately to synthetic systems or narrow domains such as smart vehicles, contact-tracing platforms, or decentralized identity systems, this study is, to the best of our knowledge, among the first to apply the combined STRIDE–LINDDUN–OWASP–NIST chain specifically to a production-grade CRM–AI analytics integration, validated against real architecture documentation and an expert panel.

4. Methodology

This section presents and justifies the methodology used to conduct the research, describing the tools, frameworks, and procedures adopted for threat modeling, structuring the results, and selecting security and privacy controls. This applied, exploratory, and descriptive study relies on a case study conducted at a Brazilian financial-sector company, examining a concrete information security problem within a cloud computing architecture, in accordance with the characterizations proposed by Gil [63] and Marconi and Lakatos [64].

The following subsections detail five main methodological stages: (i) system modeling and DFD development; (ii) threat identification and prioritization based on the OWASP Top 10:2025; (iii) threat classification according to the STRIDE and LINDDUN frameworks; (iv) selection of mitigations and controls aligned with NIST SP 800-53 Rev. 5; and (v) formulation of recommendations for enhancing security and privacy within the analyzed ecosystem.

The selection of the frameworks employed in this study was guided by criteria of methodological complementarity, adherence to the research object, and recognition by the scientific and normative community. We adopted the DFD as the architectural representation instrument because of its capacity to systematically map information flows, trust boundaries, and interactions among components, in a way that is compatible with multiple threat frameworks [6,26]. We selected STRIDE because it constitutes the most widely used security threat classification framework in system-based modeling, covering the main information protection properties [44,45].

We adopted LINDDUN as a complement to STRIDE because it is the only framework structured specifically for the privacy dimension in threat modeling, allowing researchers to capture regulatory risks, such as linkability and non-compliance, that STRIDE does not address [42,43]. The OWASP Top 10:2025 served as the external prioritization reference due to its practical relevance to API-based ecosystems, federated authentication, and cloud services, which are defining characteristics of the analyzed architecture [65]. Finally, we selected NIST SP 800-53 Rev. 5 as the normative control catalog because of its scope, granularity, and international recognition, as well as its compatibility with risk management frameworks widely adopted by public and private organizations [55].

Figure 1 presents these stages in a synthetic overview, from the representation of the system architecture to the selection of security and privacy controls, offering an integrated view of the methodological path and the logical sequence of activities that structure this research.

4.1. System Modeling and DFD Development

We conducted system modeling by systematically transforming a reference architecture from a Brazilian financial-sector company, focusing on the integration between a cloud-based customer relationship management platform and a cloud-hosted analytics environment with artificial intelligence capabilities, into a Data Flow Diagram (DFD) compatible with the STRIDE and LINDDUN approaches.

The process began with an analysis of the proposed architecture, supported by interactions with the technical team involved in the architecture, implementation, and operation activities of the environment; this analysis aimed to identify the ecosystem’s technological components, their interactions, and the information flows necessary for subsequent mapping onto the DFD’s structural elements. The same team also validated adherence to the resulting architectural translation, helping confirm the consistency of the developed model.

The architectural mapping to the DFD followed the classical logic of identifying processes, data flows, data stores, and external entities. However, it required methodological adaptations to adequately represent the analyzed context and preserve the model’s capacity to reveal relevant threats. In particular, we retained some components originally understood as external entities within certain trust boundaries when they belonged to the same trust domain as their associated processes, avoiding artificial fragmentation of the representation and the loss of threats related to interactions among elements within the same operational context.

Another adaptation used in constructing the DFD was to use bidirectional arrows for specific flows, aiming to make the diagram more visually legible and reduce graphical overload. In these cases, the bidirectional representation does not imply analytical simplification, as we considered both the threats associated with the outbound flow and those associated with the return flow of information. This graphical choice therefore sought to reconcile visual clarity with methodological consistency, without compromising the systematic identification of threats.

4.2. Threat Identification and Prioritization

An external prioritization reference widely recognized by the application security community, the OWASP Top 10, guided the selection of threats analyzed in this study.

In addition, we consulted nine security experts who had participated in implementing the proposed process; four held master’s degrees, one held a doctoral degree, and four held specialization degrees. Their practical experience helped refine the identification and prioritization of the threats most critical to the ecosystem under evaluation. Table 3 synthesizes the composition of the expert panel considered at this stage.

We employed structured consultation with experienced professionals, aligned with expert-panel approaches such as the Delphi technique, to systematize opinions on a complex real-world problem [66,67]. Table 4 presents the main elements of this expert-panel consultation, consolidating the adopted method, the objectives of data collection, and the expertise criteria.

The nature of the analyzed ecosystem justifies the adoption of this reference: because the environment comprises cloud-hosted services integrated by application programming interfaces and federated authentication mechanisms, the categories present in the OWASP list present adherence and practical relevance.

In mapping the prioritized threats, this study concentrated on the categories A01: Broken Access Control, A02: Security Misconfiguration, A04: Cryptographic Failures, A06: Insecure Design, A07: Identification and Authentication Failures, and A08: Software and Data Integrity Failures, based on empirical evidence that identifies these categories as the most prevalent and impactful failures in cloud-based web systems. Perrakis [68], in a study conducting black-box tests on ten open-source IaaS platforms, identified server misconfiguration and authentication failures as the most recurrent account-compromise vectors. Flores and Monreal [69], evaluating institutional websites using the OWASP framework, found that 94.12% of the applications analyzed presented broken access control and 88.24% exhibited security misconfiguration. Dangol [70], in a review covering APIs from more than 4,000 applications, synthesized that misconfiguration, authentication failures, and integrity problems rank among the most critical risks in API environments, a scenario directly analogous to that of cloud CRM ecosystems tightly coupled through APIs and data pipelines.

Applied studies and comparative research corroborate that these categories rank among the most frequent and severe failures in real-world applications. Haris [71] identified exploitable broken access control in more than 50% of the mobile APIs analyzed, with impacts ranging from partial data leakage to complete exposure of sensitive information. Kaur [72] classified 107 disclosures on the HackerOne platform and confirmed that 78.5% of the cases constituted instances of Broken Object Level Authorization (BOLA), reinforcing the criticality of A01 in API environments. Mangaoang and Monreal [73] reported insecure design and software and data integrity failures among the main vulnerabilities identified in empirical evaluations of institutional web applications.

Feng [74], in a longitudinal analysis of the Alipay mobile payment infrastructure, documented systematic cryptographic failures in production, exemplifying the real-world impact of A04 in large-scale cloud services. Together, these studies substantiate the prioritization of the six OWASP categories adopted in this work. The remaining OWASP categories, although relevant to secure development in general, did not undergo detailed analysis because the scope of the STRIDE and LINDDUN modeling privileged threat scenarios directly associated with access control, cryptography, identity, and software and data integrity within the evaluated environment.

4.3. Threat Classification

This study classified prioritized threats using the per-element approach, in which each threat category systematically relates to the types of elements that constitute the DFD: external entities (E), data flows (DF), data stores (DS), and processes (P). This approach structures the analysis by establishing, a priori, which threat categories inherently apply to each element type, guiding the investigation and reducing the possibility of omissions in the mapping.

4.3.1. STRIDE by DFD Element

On the security axis, the STRIDE framework organizes threats into six categories: Spoofing (S), Tampering (T), Repudiation (R), Information Disclosure (I), Denial of Service (D), and Elevation of Privilege (E), each associated with the violation of a fundamental security property, namely authentication, integrity, non-repudiation, confidentiality, availability, and authorization, respectively.

The applicability of these categories is not uniform across DFD elements: external entities remain primarily subject to Spoofing and Repudiation threats; data flows remain subject to Tampering, Information Disclosure, and Denial of Service threats; data stores remain subject to Tampering, Repudiation, Information Disclosure, and Denial of Service threats; and processes remain subject to the broadest set, encompassing Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

Based on this mapping, we classify each threat, prioritized according to the criterion defined in the previous section, with the corresponding STRIDE letter or letters, allowing researchers to identify, for each DFD element, which security properties are most vulnerable to attack vectors relevant to the analyzed system’s context.

4.3.2. LINDDUN by DFD Element

Analogously to STRIDE, we classify each identified privacy threat with the corresponding LINDDUN category or categories, allowing researchers to associate, for each DFD element, the specific privacy threats that require attention. This dual classification of security and privacy applied to the same diagram elements ensures comprehensive coverage of the analyzed ecosystem’s attack surface, integrating the technical and regulatory dimensions into a unified analysis.

On the privacy axis, the LINDDUN framework organizes threats into seven categories: Linkability (L), Identifiability (I), Non-repudiation (N), Detectability (D), Disclosure of Information (D), Unawareness (U), and Non-compliance (N), each associated with the violation of a fundamental personal data protection principle. The relationship between these categories and DFD elements also follows a differentiated distribution: external entities remain subject to Linkability, Identifiability, and Unawareness threats; data flows and data stores remain subject to the Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of Information, and Non-compliance categories; and processes remain subject to the framework’s complete set of seven categories.

4.4. Selection of Mitigations and NIST SP 800-53 Controls

The fourth methodological stage involved identifying mitigation strategies and mapping the corresponding security and privacy controls based on the catalog established by NIST SP 800-53 Rev. 5, which provides a broad and flexible set of controls to support risk management across systems and organizations. This stage aimed to propose mechanisms to reduce or eliminate the threats identified in the previous stages, in line with NIST’s guidance to use the control catalog as a basis for protection and treatment. Figure 2 illustrates the process of deriving mitigations and mapping NIST controls adopted in this study.

The selection process followed two stages. In Stage 1, defined as deriving mitigators from OWASP, LINDDUN, STRIDE, and NIST SP 800-53, we located the corresponding OWASP Top 10:2025 category for each identified threat and collected the high-level mitigation recommendations associated with that category, because the OWASP Top 10 concentrates the most critical threats and vulnerabilities together with their recommended countermeasures [75,76].

We then compared these recommendations against the control descriptions in NIST SP 800-53 Rev. 5 to select those controls whose objectives aligned with mitigating the threat in question, a practice consistent with approaches that map external mitigators or frameworks onto the NIST catalog to support control selection [56,57]. Based on the mitigation recommendations identified in the literature and in the analyzed frameworks, we then associated the selected NIST controls with these mitigators, maintaining, in each case, traceability among the threat, the mitigator, and the NIST control codes used as a basis.

We documented this final mapping in tabular format to evidence the functional and normative alignment among threat, mitigator, and control, and to allow the process to be audited or replicated in other contexts, in accordance with recommendations for using NIST SP 800-53 as a structured and reusable control catalog across different organizations.

4.5. Procedure for Formulating Recommendations

The recommendations presented in Section 5 rest on a structured process of consolidation and critical analysis of results from the previous threat modeling stages, aiming to transform the technical mapping among threats, mitigators, and NIST controls into practical, operational guidance for implementation in real-world ecosystems. The process began with an analysis of the distribution of threats identified in the DFD, seeking patterns of recurrence and threat concentration in specific diagram elements; from this analysis, we identified three strategic axes: strengthening identity and authentication mechanisms, reinforcing cryptographic protections, and continuous monitoring, in line with the prioritized OWASP categories (A01, A02, A04, A06, A07, A08) and the STRIDE and LINDDUN classifications assigned to each threat.

Once we identified the strategic axes, we consolidated the most recurrent NIST SP 800-53 Rev. 5 controls from the mapping performed in Section 4.4, grouping them by functional families and verifying the adherence between the objectives stated in the controls and the mitigation needs derived from the classified threats. These consolidated controls served as the basis for formulating recommendations that translate the mapped technical mitigators into implementation guidelines directed at architecture, operations, and IT governance teams.

Finally, we adopted a validation and refinement procedure together with the security experts who participated in the threat prioritization stage (Section 4.2). This procedure consisted of submitting the preliminary proposals to the analysts’ critical evaluation and asking them to identify potential implementation obstacles and incompatibilities with current practices in corporate cloud ecosystems.

Thus, the construction of the recommendations followed an iterative logic that began with the raw threat modeling data, progressed through the definition of strategic axes and the consolidation of NIST controls, and underwent successive refinement based on expert feedback.

5. Results and Discussion

This section presents and discusses the results of modeling the integration ecosystem between cloud CRM and AI analytics services, based on the DFD, threat prioritization through the OWASP Top 10:2025, the dual STRIDE/LINDDUN classification, and mapping to NIST SP 800-53 Rev. 5 controls.

5.1. System Modeling and DFD

5.1.1. Technical Validation of the DFD

The process began with an analysis of the proposed architecture, conducted by two researchers with prior threat modeling experience in coordination with the professionals responsible for the architecture, implementation, and operation of the environment at the studied organization. During these structured meetings, the team identified the ecosystem’s technological components, their interactions, and the information flows necessary for mapping onto the structural elements of the Data Flow Diagram (Appendix A), which the researchers developed based on the descriptions obtained and the available technical documentation. The team then submitted the DFD to a technical validation process together with the company’s IT team; in review sessions, solution architects and security analysts verified the diagram’s conformity with the real architecture and suggested specific adjustments to processes, trust boundaries, and data stores, which allowed the researchers to confirm the consistency of the model developed and its adherence to the structure of the analyzed environment.

5.1.2. DFD Coding System

To ensure traceability and cross-referencing during the threat modeling process, the researchers adopted an alphanumeric coding system that uniquely identifies each DFD element. The components are organized into four categories: External Entities (E), Processes (P), Data Stores (DS), and Data Flows (DF), each with a distinctive prefix and sequential numbering.

External Entities (E) represent actors or systems that interact with the ecosystem and are located beyond the system’s direct control boundaries. Table 5 presents the 11 entities identified.

Processes (P) represent transformations, validations, or operations performed on data within the ecosystem. The researchers identified 11 processes that comprise the authentication, authorization, and data-manipulation chain, as shown in Table 6.

Data Stores (DS) represent the persistent storage locations that the ecosystem’s processes query. The researchers identified three data stores as essential components, as shown in Table 7.

Data Flows (DF) describe the movement of information among system components. The researchers mapped 28 flows that describe the complete communication chain within the ecosystem, as shown in Table 8.

5.1.3. Threat Prioritization, Classification, and NIST SP 800-53 Mitigation Mapping

The consolidation of threats identified through STRIDE and LINDDUN indicated that the most critical scenarios in the ecosystem concentrate in the token channels (DF1–DF6), the integration flows between cloud CRM and the data and AI platform (DF7–DF27), the metadata catalogs (DS1 and DS2), and the persistent repository (DS3). This result derives from three stages: analysis of each DFD element based on the STRIDE–DFD and LINDDUN–DFD mappings; aggregation of threats by component and category, synthesized in Table 15; and prioritization of elements that accumulate multiple OWASP Top 10:2025 categories.

The token channels accumulate categories A07 and A04, while the integration flows concentrate on A01 and A04. The metadata catalogs and the persistent repository combine access or cryptographic failures with insecure design (A01/A06 and A04/A06). Although P1, P2, and P3 each present only one category, these processes occupy a strategic position in the authentication chain, connecting external entities E1, E2, and E3 to token issuance and to integrations with CRM, data, and AI services. This combination of concentration, OWASP impact, and structural relevance indicates that identification and authentication constitute the ecosystem’s principal risk axis.

In the Identification and Authentication Failures group, events involving E1, E3, DF1–DF6, and P1–P3 can compromise confidentiality and integrity from both security and privacy perspectives. The impacts include not only improper access but also lateral movement, privilege escalation, and abusive correlation of personal data. This study therefore prioritizes NIST SP 800-53 controls IA-2, IA-5, and IA-8, recommending MFA for critical identities, robust password policies, JWT token validation (signature, issuer, audience, and expiration), and blocking legacy flows that are incompatible with security requirements.

The Cryptographic Failures analysis demonstrates that flows DF1–DF27 and assets such as DS3 and P4 depend on cryptographic protection both in transit and at rest. Public APIs, internal channels, and managed cloud services amplify the impact of failures in TLS, key management, or database encryption. This study therefore prioritizes SC-8, SC-12, SC-13, and SC-28, requiring TLS 1.2 or higher, certificate validation, encryption at rest, and key protection. Operationally, this study recommends private endpoints, review of storage permissions, and tested backup and restoration routines, in accordance with CP-9 and CP-10.

Audit and monitoring controls, such as AU-2, AU-10, AU-12, and SI-4, complement these mechanisms by enabling detection of and response to attempts to exploit APIs, tokens, and AI integrations. The recommendations, therefore, concentrate on three axes: strengthening identification and authentication; cryptographic protection of data in transit and at rest; and expanding detection and response capacity.

These results converge with studies that identify access failures, weak authentication, and cryptographic gaps as recurrent vectors in cloud applications and API integrations [7,77,78]. The concentration in a small number of components also suggests the presence of single points of failure, a pattern that researchers have described in federated architectures and cloud AI platforms [5,9]. Integrated interventions across these three axes, therefore, generate meaningful gains in security and privacy. However, these gains depend on the adequate configuration of the controls provided by the cloud infrastructure.

Table 9. A01:2025 Broken Access Control threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
E7–E10	(S)(R) (L)(Id)	Segregate environments (Production/Development/Modeling/Exploration) with distinct access controls; prevent unauthorized cross-environment access; audit inter-environment access.	AC-3, AC-4, AC-6 / CM-6, AU-2 / SC-7
E11	(S)(R) (L)(Id)(U)	Apply least privilege in the shared data environment; validate IP and identity before operations; log access; minimize exposed data.	AC-3, AC-6 / AU-2, AU-12 / PT-3
DF7–DF28	(T)(I) (L)(Id)(Nr)(De)(Di)(Nc)	Validate identity and scope before transferring data; whitelist IPs (P5); segregate access by environment; minimize data in shareable metadata; block unauthorized cross-flow; ensure LGPD compliance.	AC-3, AC-4, AC-6 / SC-7, SC-8 / AU-2, AU-12, AU-13 / PT-3, SA-8(33)
DS1, DS2	(T)(R)(I)(D) (L)(Id)(Nr)(De)(Di)(Nc)	Apply least privilege in catalogs; audit SHOW/LIST/DESCRIBE operations; redact session tokens in logs; validate consent before publishing metadata; audit scope changes; ensure LGPD compliance.	AC-3, AC-4, AC-6 / PT-3, PT-4 / AU-2, AU-6, AU-9, AU-12, AU-13 / CM-6, SI-4
P6–P11	(S)(T)(R)(I)(D)(E) (L)(Id)(Nr)(De)(Di)(Nc)	Minimize data in metadata; use PII-free naming; review granted access privileges; apply least privilege; use just-in-time provisioning for temporary identities; segregate environments; use DLP to prevent exfiltration; restrict external locations to minimal access scope; log all queries and accesses.	AC-2, AC-3, AC-4, AC-6 / PT-3, SA-8(33) / CM-6, SC-7, SI-4 / AU-2, AU-6, AU-12, SI-19

Table 9. A01:2025 Broken Access Control threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
E7–E10	(S)(R) (L)(Id)	Segregate environments (Production/Development/Modeling/Exploration) with distinct access controls; prevent unauthorized cross-environment access; audit inter-environment access.	AC-3, AC-4, AC-6 / CM-6, AU-2 / SC-7
E11	(S)(R) (L)(Id)(U)	Apply least privilege in the shared data environment; validate IP and identity before operations; log access; minimize exposed data.	AC-3, AC-6 / AU-2, AU-12 / PT-3
DF7–DF28	(T)(I) (L)(Id)(Nr)(De)(Di)(Nc)	Validate identity and scope before transferring data; whitelist IPs (P5); segregate access by environment; minimize data in shareable metadata; block unauthorized cross-flow; ensure LGPD compliance.	AC-3, AC-4, AC-6 / SC-7, SC-8 / AU-2, AU-12, AU-13 / PT-3, SA-8(33)
DS1, DS2	(T)(R)(I)(D) (L)(Id)(Nr)(De)(Di)(Nc)	Apply least privilege in catalogs; audit SHOW/LIST/DESCRIBE operations; redact session tokens in logs; validate consent before publishing metadata; audit scope changes; ensure LGPD compliance.	AC-3, AC-4, AC-6 / PT-3, PT-4 / AU-2, AU-6, AU-9, AU-12, AU-13 / CM-6, SI-4
P6–P11	(S)(T)(R)(I)(D)(E) (L)(Id)(Nr)(De)(Di)(Nc)	Minimize data in metadata; use PII-free naming; review granted access privileges; apply least privilege; use just-in-time provisioning for temporary identities; segregate environments; use DLP to prevent exfiltration; restrict external locations to minimal access scope; log all queries and accesses.	AC-2, AC-3, AC-4, AC-6 / PT-3, SA-8(33) / CM-6, SC-7, SI-4 / AU-2, AU-6, AU-12, SI-19

Table 10. A02:2025 Security Misconfiguration threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
E2	(S)(R) (L)(Id)	Configure identity federation correctly; cryptographically sign and validate tokens; revoke compromised tokens immediately.	IA-2, IA-5, IA-8 / AU-2, AU-12 / SC-23
P5	(S)(T)(R)(I)(D)(E) (L)(Id)(Nr)(De)(Di)(Nc)	Strengthen IP whitelisting; validate origin on each request; prevent Server-Side Request Forgery (SSRF) through an allowlist of permitted URLs; log validations and rejections.	AC-4, SC-7 / SI-10, SC-23 / IA-5, AU-2, CM-7

Table 10. A02:2025 Security Misconfiguration threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
E2	(S)(R) (L)(Id)	Configure identity federation correctly; cryptographically sign and validate tokens; revoke compromised tokens immediately.	IA-2, IA-5, IA-8 / AU-2, AU-12 / SC-23
P5	(S)(T)(R)(I)(D)(E) (L)(Id)(Nr)(De)(Di)(Nc)	Strengthen IP whitelisting; validate origin on each request; prevent Server-Side Request Forgery (SSRF) through an allowlist of permitted URLs; log validations and rejections.	AC-4, SC-7 / SI-10, SC-23 / IA-5, AU-2, CM-7

Table 11. A04:2025 Cryptographic Failures threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
DF1–DF28	(T)(I)(D) (L)(Id)(Nr)(De)(Di)(Nc)	Ensure TLS 1.2+ on all channels; use private endpoints for internal traffic; validate certificates; apply DNS over TLS; encrypt data in transit; audit all flows.	SC-8, SC-12, SC-13 / SC-7, SC-23 / AU-10, AU-12
DS3	(T)(R)(I)(D) (L)(Id)(Nr)(De)(Di)(Nc)	Confirm encryption at rest; block direct access with misconfigured credentials; restrict external locations to minimal scope; perform periodic backups with restoration tests.	SC-28, SC-12, SC-13 / AC-3, AC-6 / CP-9, CP-10, AU-2
P4	(S)(T)(R)(I)(D)(E) (L)(Id)(Nr)(De)(Di)(Nc)	Apply mutual TLS on the transfer channel; validate the consuming application’s identity; sanitize inputs; log transfers with user context and scope.	SC-8, SC-13, IA-5 / AC-4, SC-7 / AU-2, AU-12, SI-10

Table 11. A04:2025 Cryptographic Failures threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
DF1–DF28	(T)(I)(D) (L)(Id)(Nr)(De)(Di)(Nc)	Ensure TLS 1.2+ on all channels; use private endpoints for internal traffic; validate certificates; apply DNS over TLS; encrypt data in transit; audit all flows.	SC-8, SC-12, SC-13 / SC-7, SC-23 / AU-10, AU-12
DS3	(T)(R)(I)(D) (L)(Id)(Nr)(De)(Di)(Nc)	Confirm encryption at rest; block direct access with misconfigured credentials; restrict external locations to minimal scope; perform periodic backups with restoration tests.	SC-28, SC-12, SC-13 / AC-3, AC-6 / CP-9, CP-10, AU-2
P4	(S)(T)(R)(I)(D)(E) (L)(Id)(Nr)(De)(Di)(Nc)	Apply mutual TLS on the transfer channel; validate the consuming application’s identity; sanitize inputs; log transfers with user context and scope.	SC-8, SC-13, IA-5 / AC-4, SC-7 / AU-2, AU-12, SI-10

Table 12. A06:2025 Insecure Design threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
DS1, DS2, DS3	(T)(R)(I)(D) (L)(Id)(Nr)(De)(Di)(Nc)	Test backup routines; isolate environments to prevent failure propagation; document a continuity plan; anonymize data in non-production environments.	CP-9, CP-10 / CM-2, CM-6 / SI-19, AU-12

Table 12. A06:2025 Insecure Design threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
DS1, DS2, DS3	(T)(R)(I)(D) (L)(Id)(Nr)(De)(Di)(Nc)	Test backup routines; isolate environments to prevent failure propagation; document a continuity plan; anonymize data in non-production environments.	CP-9, CP-10 / CM-2, CM-6 / SI-19, AU-12

Table 13. A07:2025 Identification and Authentication Failures threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
E1, E3	(S)(R) (L)(Id)	Enforce MFA for IdP access; enforce strong password policy; validate JWT (signature, issuer, audience, expiration); reject invalid tokens; log failed login attempts; lock out after multiple failures.	IA-2, IA-5 / AC-7, AU-2, AU-12 / SC-23
DF1–DF6	(T)(I) (L)(Id)(Nr)(De)(Di)(Nc)	Secure channels with mutual TLS; validate token integrity at every step in the chain; reject tokens with invalid claims; log the full validation chain.	SC-8, SC-23 / IA-2, IA-5, IA-8 / AU-10, AU-12
P1, P2, P3	(S)(T)(R)(I)(D)(E) (L)(Id)(Nr)(De)(Di)(Nc)	Enforce MFA for all identities; enable automatic token rotation; use short token lifetimes; employ Managed Identity for workloads; block legacy authentication flows; validate license JWT; generate alerts on bypass attempts.	IA-2, IA-5, IA-8 / AC-6, AC-17 / AU-2, AU-12, SC-23 / SI-4

Table 13. A07:2025 Identification and Authentication Failures threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
E1, E3	(S)(R) (L)(Id)	Enforce MFA for IdP access; enforce strong password policy; validate JWT (signature, issuer, audience, expiration); reject invalid tokens; log failed login attempts; lock out after multiple failures.	IA-2, IA-5 / AC-7, AU-2, AU-12 / SC-23
DF1–DF6	(T)(I) (L)(Id)(Nr)(De)(Di)(Nc)	Secure channels with mutual TLS; validate token integrity at every step in the chain; reject tokens with invalid claims; log the full validation chain.	SC-8, SC-23 / IA-2, IA-5, IA-8 / AU-10, AU-12
P1, P2, P3	(S)(T)(R)(I)(D)(E) (L)(Id)(Nr)(De)(Di)(Nc)	Enforce MFA for all identities; enable automatic token rotation; use short token lifetimes; employ Managed Identity for workloads; block legacy authentication flows; validate license JWT; generate alerts on bypass attempts.	IA-2, IA-5, IA-8 / AC-6, AC-17 / AU-2, AU-12, SC-23 / SI-4

Table 14. A08:2025 Software and Data Integrity Failures threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
E4, E5, E6	(S)(R) (L)(Id)	Inventory consumer applications and integration connectors; block legacy OAuth flows; apply mTLS; enforce minimal scopes; restrict authorized IPs; revoke idle tokens and credentials; monitor anomalous API consumption.	AC-5, AC-6 / IA-5, SC-8 / AU-12, SR-3

Table 14. A08:2025 Software and Data Integrity Failures threats in the DFD: STRIDE/LINDDUN classification and NIST SP 800-53 controls.

Item	Threat classification	Mitigations	Controls
E4, E5, E6	(S)(R) (L)(Id)	Inventory consumer applications and integration connectors; block legacy OAuth flows; apply mTLS; enforce minimal scopes; restrict authorized IPs; revoke idle tokens and credentials; monitor anomalous API consumption.	AC-5, AC-6 / IA-5, SC-8 / AU-12, SR-3

Table 15. Consolidation of threats by DFD component.

Component(s)	A01	A02	A04	A06	A07	A08	Total
E1, E3					X		1
E2		X					1
E4, E5, E6						X	1
E7–E10	X						1
E11	X						1
P1–P3					X		1
P4			X				1
P5		X					1
P6–P11	X						1
DF1–DF6			X		X		2
DF7–DF28	X		X				2
DS1, DS2	X			X			2
DS3			X	X			2

Table 15. Consolidation of threats by DFD component.

Component(s)	A01	A02	A04	A06	A07	A08	Total
E1, E3					X		1
E2		X					1
E4, E5, E6						X	1
E7–E10	X						1
E11	X						1
P1–P3					X		1
P4			X				1
P5		X					1
P6–P11	X						1
DF1–DF6			X		X		2
DF7–DF28	X		X				2
DS1, DS2	X			X			2
DS3			X	X			2

The consolidated analysis of threats identified within the OWASP Top 10:2025 categories reveal a pattern of concentration in three critical dimensions of the ecosystem: authentication and access control mechanisms, communication channels and cryptographic protection layers, and metadata definition and exposure processes. The recurrence of the same components across multiple threat categories, in both the security (STRIDE) and privacy (LINDDUN) dimensions, evidences this concentration: the token channels (DF1–DF6) and the metadata catalogs (DS1/DS2) stand out, each accumulating two threat categories, together with the chain of authentication entities and processes (E1, E2, E3, P1, P2, P3), which, although presenting only one category individually, occupy a structurally strategic position by connecting these points of greatest concentration. The overlap of classifications across the same DFD elements indicates that failures at these points can simultaneously compromise authenticity, integrity, confidentiality, and regulatory compliance, amplifying the impact of potential incidents.

In terms of recommendations, the mapped controls organize around three complementary strategic axes. The first axis, identity strengthening, requires applying MFA, robust credential policies, and systematic token validation, sustained by NIST SP 800-53 controls IA-2, IA-5, and IA-8. The second axis, cryptographic strengthening, establishes TLS 1.2+ requirements across all channels, certificate validation, and protection of data at rest, based on controls SC-8, SC-12, SC-13, and SC-28. The third axis, continuous monitoring, aims to expand detection and response capacity through controls AU-2, AU-10, AU-12, and SI-4. The integrated adoption of these controls, guided by the traceability among threats, mitigations, and normative codes established in the previous tables, provides a concrete operational basis for strengthening security and privacy within the analyzed ecosystem.

The consolidated results of this section demonstrate that the combined application of the STRIDE and LINDDUN frameworks to the ecosystem’s DFD allowed the researchers to map threats systematically and traceably, covering the security and privacy dimensions simultaneously. The token channels (DF1–DF6) and the metadata catalogs (DS1/DS2) stand out in particular, each accumulating two threat categories, together with the chain of authentication entities and processes (E1, E2, E3, P1, P2, P3), which, although presenting only one category individually, occupy a structurally strategic position by connecting these points of greatest concentration. The recurrence of these components across multiple risk fronts indicates the potential for a chain of compromises affecting authenticity, integrity, confidentiality, and regulatory compliance. This pattern aligns with expectations from the literature on integrated cloud environments, which identify federated authentication mechanisms, metadata catalogs, and integration flows as recurrent foci of vulnerabilities and privacy violations [5,41,62].

5.1.4. Discussion of Results

The threat modeling results indicated a strong concentration of risks in components related to identity, federated authentication, metadata catalogs, and integration flows between the cloud CRM and AI analytics services. This pattern corroborates evidence from studies identifying authentication mechanisms, key management, and integration interfaces as recurrent points of vulnerability in cloud architectures and API-based ecosystems [5,7,62]. At the same time, the analysis by DFD elements showed that relevant privacy and compliance impacts tend to concentrate in data repositories and in the components responsible for sharing and cataloging, in line with Privacy Threat Analysis approaches based on LINDDUN [41,42].

Threat prioritization guided by the OWASP Top 10:2025 resulted in a focus on categories A01, A02, A04, A06, A07, and A08, which suggests convergence with studies that identify access control failures, configuration errors, and cryptographic weaknesses as predominant problems in corporate cloud applications [65,79]. However, the combined application of STRIDE and LINDDUN indicates that these risks are not uniformly distributed: specific elements of the analyzed ecosystem accumulate multiple security and privacy threat categories, reinforcing the need to treat these components as risk hot spots in integrated CRM and AI analytics environments.

Compared with studies that use only security frameworks, such as STRIDE or DREAD, or only vulnerability lists, the methodological chain adopted here (DFD, STRIDE, LINDDUN, OWASP Top 10:2025, and NIST SP 800-53 Rev. 5) offers two main advantages. First, it allows researchers to maintain clear traceability among architectural elements, threat categories, and normative controls, thereby facilitating the justification of mitigation decisions to technical teams and governance bodies [6,43,56]. Second, the dual security-and-privacy approach reduces the risk of asymmetric treatment in ecosystems that process sensitive personal data, especially in the financial sector, where privacy breach incidents carry significant regulatory and reputational repercussions [5,59].

Nonetheless, applying the methodological chain to a single case study based on the reference architecture of a Brazilian financial organization limits the generalizability of the results. Reliance on information provided by experts and internal documentation may introduce biases into threat identification and prioritization, and the absence of a post-implementation empirical evaluation of the controls prevents us from establishing, at this stage, the extent of risk reduction achieved. These limitations point to the need to apply and compare this approach in other organizational contexts and sectors, as well as to combine threat modeling with evidence obtained from penetration testing, red-team exercises, and monitoring of real production incidents [38,57].

6. Conclusions

This study applied threat modeling to a corporate cloud ecosystem comprising a CRM, an analytics environment, and artificial intelligence services, aiming to identify critical vulnerabilities early and support preventive security and privacy decisions. We adopted a chained approach comprising the construction of Data Flow Diagrams (DFDs), the combined application of STRIDE and LINDDUN, prioritization through the OWASP Top 10:2025, and mapping to NIST SP 800-53 Rev. 5 controls. Unlike prior single-framework or synthetic-system studies, this configuration was validated on a real production architecture and an expert panel, ensuring end-to-end traceability among architectural elements, threats, and normative safeguards.

The results identified threats concentrated at critical points, especially within federated authentication mechanisms, metadata catalogs, and integration flows. The most relevant threats aligned with categories A01, A02, A04, A06, A07, and A08 of the OWASP Top 10:2025, evidencing the prominence of access, configuration, cryptographic, design, authentication, and software and data integrity failures in cloud environments. This pattern aligns with studies on cloud applications and APIs, but it also highlights the particularities of the integration between CRM and AI analytics within the financial sector.

Based on the STRIDE and LINDDUN classification and the mapping to NIST SP 800-53 Rev. 5, we organized the controls into three axes: strengthening identity and authentication, cryptographic protections, and continuous monitoring with auditing and incident response. The DFD–STRIDE–LINDDUN–NIST chain proves useful because it integrates architectural vision, security and privacy analysis, and normative control selection into a replicable process.

The findings depend on the reference architecture and the information provided by experts, which limits their generalizability. In addition, this study did not empirically evaluate the effectiveness of the controls after implementation. The recommendations, therefore, constitute an initial mitigation plan and require validation through penetration testing, red-team exercises, and incident monitoring.

As future work, we recommend practical evaluations of the controls through penetration testing and attack simulations, as well as prioritization models that consider asset criticality, cost, implementation effort, and operational impact. Comparative studies across other sectors and cloud architectures also prove relevant, integrating threat modeling with strategic probability and impact analyses to achieve more comprehensive risk management.