Crafting organizational security policies for critical infrastructures: an architectural approach

Architectural constructs

The principles, terminology, and artifacts surrounding the use of architectural constructs employed in this work adhere to TOGAF^[30]. To define the security architecture for the CI, we utilize the Architecture Development Method (ADM) of TOGAF, which involves identifying stakeholders, defining security concerns, and creating a comprehensive security architecture vision. the Security Architecture phase of TOGAF is then leveraged to develop a detailed blueprint for securing the CI. This includes specifying security requirements, designing security controls, and defining security patterns. Two foundational concepts underlie the TOGAF architectural design process: the Reference Architecture and the Solution Architecture.

A Reference Architecture serves as a conceptual framework that offers guidance and options for crafting specific system architectures and solution implementations. In this context, it encompasses the entirety of available architecture elements, which are instrumental in shaping a solution architecture.

A Solution Architecture, on the other hand, delves into the specifics of business operations and activities, exploring how information systems and technology underpin and enhance them. Typically, it applies to a single project or organization. In our context, it translates into a coherent assembly of architectural components, often referred to as profiles, designed to address a particular business challenge.

Thus, Solution Architecture Design refers to the process of creating a comprehensive and structured solution for a particular problem or set of requirements. It involves designing the architecture of a system or solution that addresses specific needs and aligns with organizational goals, such as the crafting of organizational security policies. This process spans multiple layers, including technology, data, application, and business architecture.

Formalism building constructs

As CIs may encompass a wide variety of systems, in order to ensure interoperability and standardized approach, our work relies on the foundations established by IHE^[31]. More in detail, we draw from its Information Technology Infrastructure Technical Framework and the related standards it incorporates and incorporate it in the overall governance scheme provided by TOGAF.

The following definitions from the IHE framework are relevant for our approach:

An IHE Actor represents a functional component within an organization. The standard-based specification governing the interactions between IHE Actors is called an IHE Transaction. A high-level functional unit consisting of interconnected IHE Transactions, which is designed to address specific IT infrastructure requirements for a particular use case, is called IHE (Integration) Profile.

A profile can incorporate functional dependencies from other profiles, as specified in grouping rules, and may inherently possess optionality and variability. Profile variability suggests that the range of transactions directly shapes and defines the functionality of the profile.

Grouping rules play a pivotal role in the organization of integration profiles. They are critical for the resolution of inter-profile dependencies, simplifying the decision-making process related to solution design. These predefined inter-profile dependencies aid in streamlining solution design by minimizing the decisions required during the design phase. For instance, if a grouping rule specifies that profile A depends on profile B, this implies that if profile A is integrated into a solution, profile B must also be included. The grouping rules are expressed in a straightforward language.

Grouping operations are instrumental in merging various profile functionalities in alignment with grouping rules. This process enables the creation of more complex use cases and lies at the core of solution architecture design.

In the IHE framework, the practical design of a solution architecture involves two key steps:

●  The translation of business requirements into a solution vision, which generates an initial subset of profiles directly derived from the use cases and their requirements.

●  The derivation of a comprehensive set of IT specifications, which expands upon the initial profiles by resolving all functional interdependencies, as outlined in the grouping rules.

Our work adopts the terms Actor, Transaction, and Profile as functional elements within the general domain of CIs, adapting the IHE concepts to suit the specific CI context. In devising the policies to apply, we rely on some well-established IHE profiles, such as the Audit Trail and Node Authentication (ATNA) Profile, which specifies the foundational elements needed by all forms of secure systems: node authentication, user authentication, event logging (audit), and telecommunications encryption. It is also used to indicate that other internal security properties, such as access control, configuration control, and privilege restrictions, are provided. Furthermore, the overall process adheres to common standards and regulatory guidelines on security, privacy and safety, industrial systems control and automation, and software architecture description, such as ISO/IEC 27002, ISO/IEC/IEEE 42010:2022, ISA/IEC 62443, IEC 61508, NIST SP 800-53 and European Union Agency for Cybersecurity (ENISA) recommendations and guidelines, among others. However, it is important to note that when implementing security and safety measures in CIs, organizations need to consider a combination of these standards based on their specific industry and operational context. Regular updates and compliance with the latest versions of relevant standards are essential to address evolving cybersecurity and safety challenges.

The novelty of our work is that it provides a way for the former to be formalized and the latter to be entirely amenable to automation, offering a structured and efficient approach to solution architecture design. In that process, the approach of TOGAF is used to identify security requirements across different architectural layers, including business, data, application, and technology layers, whereas IHE profiles are aligned with specific security requirements at each layer. In that way, we can address security goals related to confidentiality, integrity, authentication, accountability, authorization, availability, non-repudiation, and privacy across the information systems in the CI. As TOGAF emphasizes the importance of compliance with industry standards, IHE standards and profiles are integrated as part of the overall compliance strategy within the CI. The following sections present the practical implementation of these concepts and principles.

Principles of security design

At the core of the security principles guiding the design of the proposed methodology is the RMIAS^[32], which identifies four security dimensions of an Information System: Life Cycle, Information Taxonomy (Classification), Security Goals and Countermeasures, as illustrated in Figure 1 and sublimed in Table 1.

Figure 1. The RMIAS model, from Cherdantseva and Hilton. "A Reference Model of Information Assurance & Security"^[32]. RMIAS: Reference Model for Information Assurance and Security.

Unlike traditional threat-based models, which rely on statistical data about real-world threats, RMIAS follows a goal-based approach. Instead of focusing on threats, it starts from defining a set of security objectives to establish a robust methodology to cater for security. While threat-based models are suitable in the case of existing systems, where a history of past threats exists, their effectiveness is limited to the past experiences of analysts. Notably, there is a shortage of models designed to address security properties during the design phase of systems or security solutions: our approach aims to address this gap by building upon RMIAS, extending it with a Countermeasures category containing reactive safeguards to enhance system security. In contrast to threat-focused models, this goal-based method offers some advantages, including the ability to communicate security concepts effectively with stakeholders who may lack technical expertise. Their involvement not only facilitates the clarification of business goals and of the assets to protect but also highlights the need for some trade-offs early in the design phase. This, in turn, streamlines the definition of security policies and enhances organizational self-awareness, a crucial ally in cybersecurity policy management. While RMIAS does not explicitly incorporate threats, its analysis across the four dimensions yields concrete Countermeasures. These can be as concrete and threat-oriented as the system design or the organization requires (see examples in column 6 of Table 2). They can be interpreted as intended system behaviour and used for providing sound security guidance for implementation.

RMIAS takes a holistic approach to information assurance, seeking a continuous improvement of security traits throughout its Life Cycle dimension. This ensures that security is not something achieved once and for all, but rather an ongoing process, encompassing planning, implementation, monitoring, and continuous improvement. This characteristic makes RMIAS suitable for CIs, where the components are added and removed based on the specific needs, and the system varies and adapts over time.

In this paper, we extend RMIAS to specify and support the evaluation of security properties in the specific case of CIs composed of COTS. Furthermore, we formalize this process, introducing a practical evaluation tool that can support the integration process by assessing the composite system, to check if the intended security properties were preserved or went lost.

RMIAS places a significant emphasis on the creation and enforcement of security policies and procedures to guide and standardize security practices. These policies are instrumental in defining rules and responsibilities for information security. However, within RMIAS, these security policies primarily fall under the Lifecycle dimension and are not designed for modular use by other organizational processes. In contrast, a model developed by Zuccato et al.^[33] offers a versatile approach that supports the modular application of security safeguards, making it adaptable to diverse organizational requirements and threat landscapes. The core concept of this model involves breaking down security safeguards into smaller, self-contained modules, each addressing a specific facet of security, such as access control, data encryption, intrusion detection, or network monitoring. This modular approach enables organizations to mix and match these modules to create more complex "security requirement profiles", tailored to their specific security needs.

Several significant parallels exist between the approach of Zuccato et al.^[33] and RMIAS^[32]:

●  Security goals in the approach of Zuccato align with RMIAS Security goals.

●  Security safeguards are equivalent to RMIAS Countermeasures.

●  Information classification in the approach of Zuccato is akin to RMIAS's concept of Sensitivity within the Information Taxonomy dimension.

However, in addition to RMIAS, the approach proposed by Zuccato et al. introduces modularity and customization in the security design, which aligns with the realities and constraints faced by contemporary organizations^[33]. It strives for practical security solutions rather than aiming for an unattainable perfect security standard. The incorporation of modular security requirements provides predefined, cohesive, and expert-vetted security mechanisms during system conception. This approach also reduces the demand for extensive security expertise in maintaining information systems. We must also highlight that the proactive approach adopted by Zuccato et al. leads to the adoption of the term Safeguards, instead of Countermeasures, as safeguards are wider in their scope and proactive, while countermeasures are reactive^[33]. This is also a major difference between the RMIAS and our approach, as the dimension of Countermeasures in RMIAS mainly accounts for the reactive elements of countering cybersecurity threats.

Introducing modularity in the security properties

The profiles employed in our work acknowledge the interdependencies and synergies between modular safeguards and enhance them with higher-level security mechanisms, all aimed at achieving organizational security goals. However, the model proposed by Zuccato et al.^[33] does not provide a comprehensive framework for the iterative integration of these security safeguards into the life cycle of an organization, which, on the other hand, is well-covered by RMIAS^[32]. By integrating modular security requirements into the RMIAS model, a more adaptable and pragmatic approach to information security can be supported. Thus, merging these two complementary approaches into a unified framework can overcome their individual limitations.

It is worthwhile noting that the process of introducing modular security properties also adheres to the procedure for ensuring the interlinkage and usability of various system abstraction levels as defined by the Sustainability Performances, Evidence and Scenarios (SPES) framework, particularly within safety and security assessment. More concretely, SPES utilizes a hierarchical modeling technique, where systems are decomposed into subsystems and components, while each level of the hierarchy is a specific abstraction of the system. Our approach can be incorporated within SPES to use the information of detected potential hazards, failure modes, and safety-critical components and identify security threats, vulnerabilities, and countermeasures in order to ensure that security considerations are embedded throughout the entire system architecture. This ensures that models at different abstraction levels are represented in a standardized and interoperable manner, enhancing communication and collaboration among stakeholders.

Defining countermeasure categories

One of the main ideas of the empirical approach presented in Zuccato et al. is the ex-ante definition of abstract countermeasure categories^[33]. Such a task requires practical knowledge on cybersecurity and is, therefore, performed by security experts. The resulting artifact is named Security Mechanism Reference Table (SMRT), in which the categories of countermeasures are grouped by scope: System-dependent, Interdependent and Network-dependent. System-dependent countermeasures relate to the internal behavior of the individual systems. Interdependent countermeasures, on the other hand, refer to the interactions of cross-systems. Network-dependent countermeasures address the generic interactions between any two systems and encompass the pervasive infrastructure of the System of systems - the data network. The procedure of devising the SMRT and its concrete form will be explained in the next section. After defining the categories that are tailored to the organization, the next step is establishing the dependencies between Security goals and Countermeasure categories. This is reusable and, thus, generic information at the level of the organization that facilitates the definition of concrete countermeasures in future projects.

In this paper, we extend the concept of dependency between Security goals and Countermeasure categories to enable the evaluation of security countermeasures during solution architecture design.

Evaluation frame of reference

To ensure that the effectiveness of security countermeasures against the relevant security goals can be measured in a consistent and reproducible manner, it is crucial to establish a stable reference framework. In this context, we suggest a reference framework designed for assessing security during the design or redesign phases. To create this reference framework, the following functionalities need to be in place:

●  The security countermeasures should be described in a more functional rather than technical way, in order to foster reuse;

●  The definition of dependencies between Security goals and Countermeasure categories should be clear and stable, allowing comparable results;

●  The definition of the scope for the Countermeasure categories should be adapted to encompass the whole system;

●  The countermeasure categories should act as a proxy to evaluate if the concrete (solution-dependent) countermeasures meet the intended security goals.

The methodology presented in the upcoming section facilitates the implementation of these functionalities and the establishment and maintenance of such a reference framework as an integral part of the security policy of a CI. The creation of this evaluation framework is described next.

Modeling security requirements

It is important to note that the RMIAS expansion does not merely hold profound implications for the security of the CI but also bears significance in the broader context of organizational management. From a technical perspective, this augmentation embodies two fundamental components. First, it involves the extension of the existing RMIAS tuple with an additional dimension, enabling the systematic categorization of countermeasures. Second, it facilitates the creation of a formal representation for this entire process. Henceforth, this enriched tuple is designated as "Security requirement". The culmination of this effort is a comprehensive set of Security requirements, forming the bedrock of the Security Policy.

The newly introduced dimension, supplementing the existing four RMIAS dimensions, is denoted as the Countermeasure category. This category, from a formal viewpoint, includes a predefined set of values. Selecting these values is based on established dependencies within the broader spectrum of Security goals. As a result, the process involves classifying the information to be protected based on the Information Taxonomy, identifying the subset of Security goals through rigorous risk analysis, and deriving the System-dependent, Interdependent, and Network-dependent Countermeasures categories from a table of pre-defined dependencies. This extension further introduces an additional task: identifying suitable modular countermeasures from the SMRT for each specific category.

Each Security requirement, for the sake of comprehensiveness, encompasses the following attributes: Form, Sensitivity, Location, State, Security Goal, Countermeasure Category, and Countermeasure.

The concept of a Security requirement stands at the core of our work and plays a pivotal role in shaping the definition of a Security Policy. Its presence confers several notable advantages, including:

●  The capacity to classify and reuse security requirements;

●  A focused reassessment of security properties during the design phase;

●  The harmonization of system requirements with the intended security goals.

Moreover, this approach lends itself to formalization, thereby enabling the automated evaluation of a specified set of quality attributes.

The next section describes how to develop the Security Policy documents, starting from the security requirements.

Building a security policy

The development of a Security Policy document typically requires the expertise of security professionals. In this work, we provide empirical evidence regarding the practicality of Security Policy and its applicability in everyday project design scenarios. Our objective is to steer away from a scenario where Security Policies serve as neglected repositories, seldom utilized and rarely revisited, moving towards a scenario where they are stable and equipped with systemic tools for compliance, maintenance, and evolution. Figure 2 offers a visual representation of the Security Policy development process.

Step 1 revolves around the definition of Countermeasure categories, organized by scope (e.g., System-dependent, Interdependent, and Network-dependent), and tailored to the specific context at hand. Following the approach in^[33], the outcome of this step is a SMRT specifically designed for CI applications, designed by security experts.

Step 2 is targeted at establishing the values of the Information Taxonomy (classifiers) and the Security goals within the RMIAS. While the former can be adapted to the CI's context, the latter typically comprises the eight major RMIAS security goals: Accountability, Auditability, Authenticity/Trustworthiness, Availability, Confidentiality, Integrity, Non-repudiation, and Privacy (see^[32] for detailed description and rationale).

In Step 3, the organization must determine its level of ambition, selecting which security goals it aims to achieve based on the output from Step 2 and performing business risk analysis. Although, in principle, all identified security goals should be pursued, this step serves as the initial point for discussions among security experts, architects, and management, considering practical business constraints. The reason for this is that it often appears that business constraints may (at least temporarily) dictate different ambitions for the security requirements.

In Step 4, the experts scrutinize the security goals agreed upon in Step 3. This analysis aims to identify the dependencies of the countermeasure categories to be included in the SMRT. The outcome, a list of dependent countermeasure categories per target security goal (see an example in Table 3), should be a stable artifact within the Security Policy document, constituting the first pillar of the evaluation frame of reference. These dependencies can subsequently be formalized to enable the automated assessment of security properties.

Step 5 creates the Security Policy rule set, forming the second pillar of the evaluation frame of reference. To evaluate the security properties of a given solution architecture, one approach is to ascertain whether the Countermeasure categories in the concrete security properties can address dependencies of all security goals identified in Step 4. However, this approach focuses on one-to-one dependencies, excluding broader interdependencies.

Therefore, we introduce a set of policy rules designed to manage all artifacts simultaneously: the SMRT, the collection of security requirements, and the dependency table. These rules not only ensure compliance with security goals and countermeasure categories but also streamline security evaluation during the design phase. When it comes to security requirements, specific rules cannot be expressed in terms of concrete countermeasures since those are not predetermined. To address this, we use established countermeasure categories as substitutes or proxies in our rule formulations.

In our work, we formalize these rules to enable a more detailed evaluation of security requirements within solution architecture design.

Step 6 centers around the definition of baseline security requirements. Employing the methodology delineated here, the security team orchestrates a second round of interactions between security experts, architects, and business stakeholders, critically assessing the trade-offs presented by each security requirement.

Step 7 represents a major milestone in our work, offering a tool to validate the alignment of baseline security requirements with dependencies and the policy rule set established in previous steps. This step ensures not only the consistency of baseline countermeasure requirements but also their coherence with the Security Policy rule set, establishing holistic consistency for the Security Policy.

Finally, we introduce a feedback mechanism, underlining the Information System Security Life-cycle dimension within the RMIAS model to guarantee the active maintenance, evolution, and relevance of the Security Policy. The subsequent section expounds on the process of evaluating solution architecture by leveraging the resultant Security Policy.

Evaluating architecture solutions

Building upon the RMIAS model and the formulation of a stable, coherent Security Policy, we have provided a framework that facilitates a consistent and repeatable security assessment of solution architectures. In a similar manner, we can automate the evaluation process by extending the architectural framework that was presented in our previous work^[4] based on the mechanisms depicted in Figure 2.

The proposed structure for security requirements, detailed in Section 5.1, can be expressed in a formal syntax. Therefore, we can expand the profile construct defined earlier, in order to enable modularity and interoperability.

Due to their modular and self-contained nature, we can draw a clear parallel between a system assembled from a set of base profiles and a complex system resembling a CI. Thus, the findings derived from solutions composed of profiles are readily applicable to the CI context.

Let us begin by assuming that, for the purposes of this paper, solution architectures are assembled from modular profiles, which act as their component building blocks. As explained earlier, these profiles incorporate various modular security requirements and undergo the same consistency tests described in Steps 6 and 7 of Figure 2. Nevertheless, the design team, ideally including individuals with security knowledge and expertise, can introduce additional, project and CI-specific security requirements as required. Consequently, after assembling the profiles to compose a new solution, the following security requirements become integral to the architecture:

●  Baseline security requirements: originating from the Security Policy document and, by definition, applicable to all solutions;

●  Profile security requirements: inherent to the selected profiles;

●  CI-specific security requirements: project-specific and CI-specific requirements.

The entirety of these security profiles is evaluated as a cohesive unit, irrespective of their origin. Figure 3 outlines the steps of the proposed evaluation process.

Figure 3. Evaluating security requirements of solution architectures.

In Step 8, the architectural team conducts CI-specific analysis following the extended RMIAS process, as previously elaborated. This step may also reveal additional security requirements.

Step 9 involves the evaluation of the merged set of security requirements (baseline, built-in, and project-specific) against the same frame of reference provided by the Security Policy, as described earlier. Incorporating baseline security requirements is obligatory, but it does not guarantee consistency, compatibility among all security requirements, or compliance with the specific solution. Therefore, the inclusion of baseline security requirements is performed as a mandatory step.

Finally, Step 10 presents the feedback loop of the evaluation, enabling architects to follow a test-driven, iterative approach in building the solution architecture.

As illustrated in Figures 2 and 3, Steps 7 and 9 are conducive to automation. In the subsequent section, we delve into the formal mechanisms that facilitate this automated process. It is important to underscore that the entire design and evaluation cycle is carried out either by the architectural team of an organization or by experts, albeit with the assistance of workflow automation tools. This consideration is crucial for leveraging efficient reasoners and tools, which are grounded in propositional logic and calculus. Moreover, it aids in devising new countermeasures, such as in Step 8, where the predefined set of countermeasures may not suffice to address the risk. In such cases, a fully automated workflow would not yield a conclusive outcome.

Defining the formal language

To leverage the formal syntax from Section 6 and demonstrate its practical utility, we have developed a comprehensive tool-chain that enables architects to build-up solutions, which can subsequently be assessed against a predefined set of metrics. These metrics may encompass various aspects, such as security goals and Service Level Agreements (SLAs).

Similar to any other software asset, architectural blueprints can require changes over time due to factors such as evolving requirements, variations in the legal landscape, or the natural progression of the project. To facilitate this dynamic process, we automate the evaluation of the impact of these modifications on the desired metrics through a Satisfiability Modulo Theories (SMT) solver. These metrics can include security- and non-security-related SLAs. In this way, we provide the architects with the capability to modify the architecture and its components and evaluate the impact of the changes.

Consider the scenario where stakeholders request cost reduction. In response, the architect can explore various strategies by exchanging different modules and identify new combinations that potentially reduce costs. For each proposed change, our solution identifies dependencies among the modules and assesses how these changes affect the metrics, in a semi-automatic fashion, ensuring compliance with the customer's specifications for service level agreements.

To support this dynamic capability, we employ a formal (denotational) syntax for the IHE methodology [Table 4]. In addition, we present a method for encoding security goals (and quality attributes) in a manner that enables an automated evaluation of their fulfillment. The encoding is expressed as SMT-LIB, a standard language for formal reasoning, allowing for the efficient and systematic assessment of architectural changes against predefined metrics, thereby ensuring the ongoing alignment of the architecture with the evolving needs and objectives of the project.

After the definition of a formal syntax, we can introduce the related semantics, mapping the items of our theory to our real-world use case, described above.

Two profiles are encoded for that purpose: XDS (mentioned above) and an ATNA profile, due to the security requirements explained. Being a pure content profile (e.g., providing clinical document management), XDS only states as $$\textsf{security_requirements}$$ the form of its data (Electronic) and where XDS documents can be disclosed (providing no constraint on the location, XDS being document agnostic). On the other hand, ATNA provides for a strict security requirement: it targets as goal confidentiality during transmission.

Building security policy and evaluating security requirements

While the accountability of transactions is effectively managed by the audit trails sent via ATNA, a critical piece of information is still missing: the identity of the individual who performed the action. The question arises: How can we authenticate and confirm the identity of the principal, and how can this authentication be corroborated by a third party?

ATNA currently establishes mutually authenticated channels, primarily achieved through TLS. However, there is a notable infrastructure limitation to this approach. In practice, active intermediaries must be assumed because it is neither realistic nor feasible to envision a direct connection from a device such as an X-ray machine to a regional repository. Consequently, it becomes imperative to address principal authentication at a higher ISO/OSI level, specifically at the application layer. Now, let us consider a scenario where we have an $$\textsf{ArchitecturalElement}$$ encompassing these profiles, all of which are equipped with a mandatory grouping rule linked to ATNA. Notably, external sources rely on TLS channels for communication, while the clinics leverage robust authentication provided by Cross-Enterprise User Assertion (XUA) registry to access documents.

Upon passing this architectural element to the grouping function, the resultant output will include the profiles and the security requirements, as outlined in Table 5. This table comprises the evaluated security requirements inherited from the amalgamation of all the profiles. It serves as a comprehensive reference that can be consulted to verify whether the security policy, as defined by the RMIAS model, aligns with it.

However, it is worth noting that since security policies are expressed in plain text, and given the multitude of available formalism for encoding security policies, we opt to return the table as is. This approach provides flexibility, allowing the organization or the architect to select the most suitable format for their specific needs (For instance, our implementation offers support for LUA and BeanShell as languages to query the security requirement table, ensuring that the chosen format aligns seamlessly with the preferred practices and requirements of an organization.).

In the interest of clarity in the following discussion, we introduce a trivial operator, denoted as $$ \sigma_{\underline{k}} $$. The operator functions akin to the selection operation in relational algebra. In practical terms, when applied to a security requirement set denoted as $$ S $$, which results from a grouping operation, $$ \sigma_{\underline{k}} $$ returns all the values for the columns specified by $$ \underline{k} $$. Our project encompasses a comprehensive security policy set, as outlined in Table 6. When we execute the $$ \sigma $$ operator defined in the table, we uncover a critical architectural incongruity, one that does not align with the prescribed security policy. Specifically, let us examine the security policies within the set:

●  Security policy with ID 1 returns a favorable ok status, as it meets the condition of having at least one category for data confidentiality transfer protection.

●  Security policy with ID 2 similarly returns an ok status because it possesses an accountability building block, as provided by satna2.

●  However, security policy with ID 3 encounters an error, as there exists an entry that lacks strong authentication for confidential data, specifically health data. This policy, denoted as es1, permits users without strong authentication to access confidential data within a partially controlled location. This issue is illustrated in Figure 4 and is rectified in Figure 5.

Figure 5. Case Ⅱ: The Central Registry use case: this diagram illustrates the final configuration of the Regional Healthcare System architecture, after the evaluation and the fixing performed using the illustrated methodology. In this case, the external source must pass through the Identity Management Subsystem to access the Repository.

The depicted scenario [Figure 6A] shows the "External Source" within Security Zone 3 (Partially Controlled) accessing health data without passing through the ID Management module. The straightforward architectural solution is to reroute the "External Source" to the ID Management component and adjust es1's goal to incorporate Strong authentication.

Figure 6. Graph showing dependencies between IHE profiles (Grouping Dependencies): in (A), the diagram shows the dependencies among the profiles for the initial configuration of the Central Registry use case, as illustrated in (B), it is noteworthy that a security gap exists, as some profiles do not depend on XUA, while Figure 4 displays the dependencies between the profiles in the IHE IT Infrastructure Technical Framework, we can immediately detect that all the profiles depend on ATNA. IHE: Integrating the Healthcare Enterprise; XUA: cross-enterprise user assertion; IT: information technology; ATNA: Audit Trail and Node Authentication.

In modular architectural models, including the SGAM and IHE, security profiles play a crucial role by acting as mandatory groupings for all other profiles. This practice ensures that security considerations are integrated into all phases of the system deployment lifecycle. This concept is explicitly illustrated in Figure 6B, where the ATNA profile is inherited by all other profiles, thereby providing TLS transactions for all IT-based health projects within the IHE framework.

Similarly, Figure 6A illustrates the same principle, with ATNA being referenced by "clinic", "XDS", and "ExtSource" (for External Source). These examples highlight the importance of the tools that allow for a graphical visualization of the dependencies, as they improve the overall usability of the conceptual framework and, more generally, streamline the whole process. For example, looking at Figure 6A, it is easy to note that a security gap is present where "ExtSource" and "XUA" lack a direct connection. This underscores a similar concern identified by security policy es1, indicating that "ExtSource" lacks strong authentication since it is not grouped with "XUA". This architectural insight is essential to maintain the integrity of the system from the security point of view.

Acknowledgments

The authors acknowledge the valuable contribution of Dr. Massimiliano Masi in terms of comments and feedback on the content of the paper, as well as his suggestions on the use case provided. The authors highly appreciate his time and effort on making the paper technically solid.

Authors' contributions

Made substantial contributions to conception and design of the study: Pavleska T, Sellitto GP

Contributed to the definition of the methodology and the choice of the use case, as well as the full revision of the paper: Pavleska T, Sellitto GP, Aranha H

Defined the application of the methodology to the use case and the overall conceptual framework: Pavleska T

Performed the adjustments of the formal syntax to the use case: Aranha H

Set the scope and further revised the paper to meet the objectives: Sellitto GP

Availability of data and materials

The data model and the formal language supporting our findings can be found at: https://github.com/mascanc/MOSA2.

Financial support and sponsorship

None.

Conflicts of interest

All authors declared that there are no conflicts of interest.

Ethical approval and consent to participate

Not applicable.

Consent for publication

Not applicable.

Copyright

© The Author(s) 2024.