# Cybersecurity Evaluation of Enterprise Architectures:
The e-SENS Case

Tanja Pavleska, Helder Aranha, Massimiliano Masi, Eric Grandry, Giovanni

Paolo Sellitto

► To cite this version:

Tanja Pavleska, Helder Aranha, Massimiliano Masi, Eric Grandry, Giovanni Paolo Sellitto. Cybersecurity Evaluation of Enterprise Architectures: The e-SENS Case. 12th IFIP Working Conference on The Practice of Enterprise Modeling (PoEM), Nov 2019, Luxembourg, Luxembourg. pp.226-241, 10.1007/978-3-030-35151-9_15. hal-03231354

HAL Id: hal-03231354

https://inria.hal.science/hal-03231354

Submitted on 20 May 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Cybersecurity Evaluation of Enterprise Architectures:
The e-SENS Case

Tanja Pavleska¹, Helder Aranha², Massimiliano Masi³, Eric Grandry⁴ and Giovanni Paolo Sellitto⁵

¹ Jozef Stefan Institute, Jamova 39, Ljubljana
atanja@e5.ijs.si

² Public Administration Shared Services Entity, I.P., Alfragide, Portugal
helder.aranha@espap.pt

³ Tiani Spirit GmbH, Vienna, Austria
massimiliano.masi@tiani-spirit.com

⁴ Ministry of Mobility and Public Works, Luxembourg
eric.grandry@tr.etat.lu

⁵ Autorità Nazionale Anticorruzione, Italy
g.sellitto@anticorruzione.it

**Abstract.** Technology management through enterprise architectures has already become a widespread practice across large enterprises. Modeling and evaluating the cybersecurity aspect of it, however, has just begun to get the needed attention. This paper presents a cybersecurity evaluation methodology developed for the reference architecture of the e-SENS project and derives a generic framework for cybersecurity evaluation of an enterprise architecture. The evaluation addresses both the high-level design artefacts (the reference architecture) and operational solutions. Therefore, both a conceptual and an empirical framework are developed as part of the methodology. The former extends a goal-based security model with a threat-view incorporating standardized guidelines on security measures, whereas the latter captures and systematizes implemented project-specific security practices. The resulting methodology effectively supports the evaluation and is easy to grasp by non-technical people. Moreover, it is lendable to formalization, supporting a semi-automatic process of solution architecture design.

**Keywords:** Cybersecurity, Enterprise Architecture, e-SENS, Evaluation methodology, Framework.

## 1 Introduction

Supporting the management of technology by enterprise architectures, while essential and useful, poses additional requirements for effectiveness and efficiency, such as: accounting for the life cycle of the different aspects and attributes of the architecture (interoperability, (cyber)security, change management, variability, etc.). Various models to address these requirements have been proposed [1]–[3]. However, they mainly address small-scale solutions, lack an account of a standardized process of technology
management or require fully manual work on the issue under consideration. In this pa-
per, we present a cybersecurity evaluation methodology developed for the reference
architecture of the e-SENS project.<fnref n="1" /> The aim is to derive a generic framework for cy-
bersecurity evaluation of enterprise architectures that would be interoperable, applica-
ble to both small and large-scale scenarios, understandable by non-technical people, but
also technically sound to the extent that it is fully automatable and reusable.

The Electronic Simple European Networked Services (e-SENS) project aimed at de-
livering reusable architecture Building Blocks (BBs throughout this paper) for the im-
plementation of cross-border and cross-sector digital services. In addition to developing
BBs as elementary parts of the e-SENS Reference Architecture (e-SENS RA), corre-
sponding implementations in several domains were piloted (eHealth/ePrescription,
eProcurement, eJustice, Business LifeCycle and eAgriculture), providing a proof of the
architecture feasibility and effectiveness. The e-SENS approach adopts the TOGAF9
concept of a building block [1]. The BBs are combined and consolidated into Solution
Architecture Templates (SATs), as used by the European Interoperability Reference
Architecture<fnref n="2" />, and address specific real-world use-case. The BBs are described along
common dimensions, captured by the e-SENS Metamodel [4]. The availability of solu-
tion templates not only facilitates the use of the BBs, but guides developers in the real-
ization of custom solution architectures. In doing so, significant challenges appear due
to the requirements for architecture solutions and the standards and security solutions.
Thus, an evaluation methodology is needed that is applicable at architectural level, but
which also presents the various features in a uniform way for all of the BBs.

The evaluation presented in this paper includes model-based assessments at SAT-
level from the aspect of (cyber)security. Although designed for e-SENS, the methodol-
ogy has been generalized and proven applicable for other contexts as well [5]. It com-
bines two complementary evaluation frameworks: conceptual and empirical. The for-
mer builds on a standard goal-based security model known as the Reference Model for
Information Assurance & Security (RMIAS) [6]. This model was augmented by a
threat-view incorporating the ENISA guidelines on security measures [7] to provide a
holistic account of the security properties of the reference architecture. The empirical
framework, on the other hand, is an evaluation tool for the pilots, designed according
to the conceptual framework. It captures and systematizes the security practices de-
ployed in the solutions based on the reference architecture and provides recommenda-
tions on how the BBs' specifications can be fine-tuned to meet the security goals.<fnref n="3" />

This paper is structured as follows: the next section introduces the two parts of the
evaluation methodology – the conceptual and empirical evaluation frameworks. Each
is supported by a relevant discussion or recommendations related to the obtained re-
sults. Then, our work is placed among the state of the art approaches. Finally, we con-
clude and point to some future work plans.

<footnote n="1">¹ https://www.esens.eu/</footnote>

<footnote n="2">² https://ec.europa.eu/isa2/solutions/eira_en</footnote>

<footnote n="3">³ Note that the terms “security” and “cybersecurity” are used interchangeably throughout the paper: while the RMIAS addresses information security (& assurance) in general, the evaluation described here focuses on cybersecurity, as information in e-SENS is mainly in electronic form.</footnote>
## 2 Methodology: The Conceptual Framework

The conceptual framework aims at assessing how the technical specifications contribute to meet the security goals. Two approaches are usually followed in the practice of information assurance and security: a goal-based and a threat-based approach [8]. The former defines the security goals, and then selects the countermeasures to reach these goals [9]. The latter analyzes the threats and vulnerabilities of the system to be secured, and then selects countermeasures mitigating the threats and vulnerabilities [10]. In a cybersecurity evaluation at architecture level, a goal-based approach is usually taken, as a threat-based requires detailed analysis of all system vulnerabilities, and a detailed knowledge of the system behavior history. Such data is not available at system design.

The objective of the proposed methodology is twofold: 1) the core security goals must be general enough to address all of the domain needs; and 2) they should be applicable to any architecture derived from the BBs. Therefore, both a goal-based and a threat-based approach are combined in this work in a coherent manner.

**Fig. 1** depicts the application of the conceptual framework to the e-SENS System, which is represented in the core diagram with all its assets: Network, Hardware, People, Information, etc.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** The conceptual framework of the cybersecurity evaluation</figcaption></figure>

The security aspects (i.e. dimensions) composing the RMIAS goal-based view are: *Security Development Life Cycle* SDLC (represented in green), *Information Classification* (which corresponds to the RMIAS taxonomy), *Security Goals* (in orange) and *Countermeasures* (in blue).

* SDLC illustrates how security is built up along the system development life cycle;

* Information Taxonomy characterizes the nature of information being protected;
* Security Goals contain a broadly applicable list of eight security goals: Confidentiality; Integrity; Availability; Accountability; Authentication (and Trustworthiness); Non-repudiation; Privacy and Auditability.

* Countermeasures categorize the countermeasures available for information protection.

To address the threats and vulnerabilities of the system, the goal-based model is complemented by a threat-view, which is represented by the purple blocks in Fig. 1.

## 2.1 RMIAS and the goal-based view

The evaluation is preceded by goal-based modeling, performed along each of the RMIAS dimensions. Information classification helps to understand the relevant security goals associated with the system under evaluation. Information is classified by:

- Form: in e-SENS information is exclusively manipulated in electronic form;

- State: in e-SENS it can be in one of the following states: Creation, Transmission, Storage, Processing, Destruction;

- Sensitivity: in e-SENS it can be either confidential, or non-confidential;

- Location: in e-SENS it is always at controlled locations.

The e-SENS System can be described through different views; in this evaluation, we concentrate on the architecture description relevant to the various eServices. The evaluation includes the cross-border SATs that were most employed by the pilots while carrying the bulk of the security mechanisms: eID, eDelivery, Non-repudiation, Trust Establishment, eDocuments, and Semantics [11]–[13].

The goal-based assessment is performed as follows:

1. The architecture of the system to be protected is described, and the various stages of information manipulation are identified;

2. For each stage, the information is categorized according to the information view of the security model. The associated security goals are deduced by the security expert performing the evaluation (See Table 1 for example);

<table><caption>Table 1. Information Classification template for the SATs; an example.</caption><thead><tr><td>Information</td><td>Sensitivity</td><td>Location</td><td>State</td><td>Security Goal</td></tr></thead><tbody><tr><td>Authentication Request</td><td>Non-Confidential</td><td>Controlled</td><td>Transit</td><td>Integrity</td></tr><tr><td>Secure message transfer</td><td>Confidential</td><td>Controlled</td><td>Transmission, Storage</td><td>Authentication, Non-Repudiation</td></tr><tr><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td></tr></tbody></table>

3. The security goals devised are then analyzed and classified in relation to the relevant architecture (as shown in Table 2). The most generic description for each column is Node_X - Node_Y; this refers to information exchange in three general cases: (a) National infrastructure (b) Cross border infrastructure and (c) Direct end-to-end.
<table><caption>**Table 2.** Template for goal-based end-to-end analysis of each SAT</caption><thead><tr><th colspan="2">Name of the SAT being evaluated</th><th colspan="5">Point of assessment</th></tr><tr><th></th><th></th><th>End-point 1</th><th>Node A</th><th>...</th><th>Node X</th><th>End-point Y</th></tr></thead><tbody><tr><td rowspan="7">SECURITY<br>GENDER</td><td>Access Control</td><td>Yes</td><td>Yes</td><td></td><td>...</td><td>Yes</td></tr><tr><td>Authentication</td><td>Yes</td><td>Yes</td><td></td><td>...</td><td>Yes</td></tr><tr><td>Confidentiality</td><td>No</td><td>Yes</td><td></td><td>...</td><td>No</td></tr><tr><td>Integrity</td><td>Yes</td><td>Yes</td><td></td><td>...</td><td>Yes</td></tr><tr><td>Non-repudiation</td><td>No</td><td>No</td><td></td><td>...</td><td>...</td></tr><tr><td>Accountability</td><td>...</td><td>...</td><td></td><td>...</td><td>...</td></tr><tr><td>Auditability</td><td>...</td><td>...</td><td></td><td>...</td><td>...</td></tr><tr><td></td><td>Privacy</td><td>...</td><td>...</td><td></td><td>...</td><td>...</td></tr></tbody></table>

## 2.2 ENISA guidelines on security measures and threat-based view

The ENISA guidelines on security measures sublimate an extensive list of national and international EU electronic communications standards into a set of security objectives divided by domain [7]. They outline 25 security objectives, each analyzed through various security measures and supported by evidence testifying that an objective was met. The security measures are grouped in 3 sophistication levels, whereas the security objectives are divided in 7 domains of application. This provided a suitable framework of complementary views to the goal-based security evaluation.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Relevance of the ENISA guidelines in the context of e-SENS</figcaption></figure>

As information is the main security asset in e-SENS, many of the ENISA security measures and objectives were not addressed by the evaluation. To determine those that
are relevant for e-SENS, a mapping of the contextual and security traits between the e-
SENS security needs and the ENISA provisions is performed, as presented in **Fig. 2**
showing the whole set of ENISA security objectives divided by domains. To represent
the relevance for the e-SENS context the boxes are colored and assigned the following
semantics: red denotes the relevance of that particular security objective (SO) for the
evaluation in the concrete domain (Dx); green represents the SOs for which e-SENS
can provide recommendations to future adopters of e-SENS building blocks; and trans-
parent (white) boxes denote that the SO is not relevant for the evaluation purposes.
Mapping the contextual and the security traits of RMIAS to the ENISA framework
provides sufficient practical and scientific rigor in accomplishing the task of a holistic
cybersecurity evaluation. Moreover, it enables the extraction of specific guidelines and
recommendations for the security measures that must be adopted to meet the objectives.

## 2.3 Integrating RMIAS dimensions and ENISA objectives

Mapping RMIAS to the ENISA technical guidelines establishes correspondence be-
tween each of the RMIAS dimensions and the ENISA Security objectives by domain.
It is represented as a matrix: each entry that lays at the intersection of an RMIAS row-
entry and an ENISA column-entry contains the information about the reciprocal rele-
vance of the two. The same matrix can also contain the results of the assessing of rele-
vance in the specific context. Such results are denoted by red-green-white coloring the
particular entry, with the same meaning as presented in the previous section.

As Information is the main asset to be protected by the security mechanisms speci-
fied by the e-SENS RA and implemented by the pilots, the mapping of Information
Taxonomy is granulated into: Creation, Processing, Storage, Transmission, and De-
struction. The result is a 25x25 matrix (see Table 3) with one additional dimension for
Relevance represented by a particular color, as explained previously. This additional
dimension can be further fine-grained, for example by giving it numerical weights. It
enables a threat-view by domain for each goal-based dimension and its sub-dimensions.
Providing a threat-view starts as a subjective assessment, as the decision to denote a
particular table entry as relevant or not depends on the analyst's expertise and experi-
ence. This is also one of the inherent drawbacks of a threat-based method. To ensure
the least bias possible, the evaluation has been reviewed by more experts who were
involved in both the design of specifications and in pilot implementations. The most
important result from this cybersecurity evaluation, however, is the methodology itself,
which not only is it not subjective, but is based on rigorous standards and scientific
approaches.

To give an example, we can refer to the goal-based analysis of the pilots (presented
in Section 3.2). There, we show that the security goal Availability requires proper ac-
count. In Table 3, there are 19 security objectives that provide a threat-view of Availa-
bility relevant for e-SENS across all 7 domains. Eight are mandatory (in red) for spec-
ification and implementation, whereas for 11 (in green) e-SENS provides recommen-
dations to future adopters. Depending on the domain, a catalogue of security objectives
can be designed to guide the specification and implementation of relevant security
measures. Governance and risk management can be similarly addressed.
<table><caption>**Table 2.** Mapping RMIAS to ENISA guidelines by relevance for e-SENS security mechanisms</caption><thead><tr><th rowspan="2">RMIAS</th><th colspan="15">ENISA guidelines</th></tr><tr><th>D1</th><th>D2</th><th>D3</th><th>D4</th><th>D5</th><th>D6</th><th>D7</th></tr></thead><tbody><tr><td>Confidentiality</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>integrity</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Availability</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Privacy</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Authentication</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Non-repudiation</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Accountability</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Auditability</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Security goals</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Creation</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Processing</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Storage</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Transmission</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Destruction</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Form (Electronic)</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Sensitivity</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Location</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Information taxonomy</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>State</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Information taxonomy</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Technical</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Countermeasures</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Organizational</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Human-oriented</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>System</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Countermeasures</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Design</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Implementation</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Management and monitoring</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Security lifecycle</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Redundancy and fault-tolerance</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>System retirement</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

Finally, it is worth noting that this table can further be checked for compliance with international standards by comparing it against the mapping of ENISA's domains and security objectives to international standards in Section 6 of the ENISA report [7].

## 2.4 Discussion

The evaluation of the e-SENS SATs demonstrated that the specifications are grounded on well-established security standards and solutions. Furthermore, all security goals can be addressed by adopting one or a composition of BBs. Information in all its states and locations can be adequately accounted for, depending on its sensitivity, in order to de-vise a certain security goal. One of the most important traits of the e-SENS RA is that its BBs are fully interoperable. This implies that by interconnecting the relevant BBs, a certain security property can be leveraged to meet a desired security goal.

By presenting a high-level overview of the architecture to which a security mechanism applies, and by providing a catalogue of the security goals addressed by each of the SATs, a non-technical person is able to grasp the potential of a certain solution to satisfy given security requirements. Moreover, by providing a detailed elaboration of the technical processes behind a solution and reference to the standards on which it is based, a technical person gets the support to build a conceptual evaluation model to satisfy the desired security goals. Hence, the analysis performed here provides a common ground for understanding between various levels of experts in a given organization. It also helps to organize the security policies spread over multiple domains. Furthermore, it not only permits tracing contradictory security policy statements, but also facilitates the identification of weak or omitted security policies. Complemented with the more domain-specific security measures offered by the threat-based analysis, it may
contribute to more cost-effective and efficient solutions for both public administrations and private organizations. Finally, the modularity of the analysis by security domain, objective, goal and countermeasures allows to detect opportunities for further improvement of both the system/architecture and the implemented security mechanisms.

# 3 Methodology: The Empirical framework

To provide a holistic view of the cybersecurity evaluation of the architecture and validate the conceptual framework as a generic methodological tool, an empirical framework was devised. This framework aims to close the gap between concept and realization. A questionnaire<fnref n="4" /> was deemed as the most effective method to gather information, given the time-frame available. It was designed to extract expert knowledge and experience from the implementation of security mechanisms in the pilots. In addition to the security aspects, some general system properties were also investigated. The results obtained with the empirical evaluation framework directly answer to the objectives of this work, while providing insights into the interdependencies between the BBs' specifications and their implementations.

## 3.1 Questionnaire design

The questionnaire design follows the RMIAS premises. It contains five sections: four focus on the RMIAS dimensions (Security goals, Countermeasures, Information Taxonomy and System Security Lifecycle), and one obtains information about Trust models implemented by the pilots. The results from the questionnaire in turn fed the threat-view analysis of the architecture, providing the needed knowledge about the system behavior and establishing a feedback loop between the design specifications and the architecture implementation. Moreover, they provided valuable insights into how the SATs address the same security objectives as the architecture building blocks they are composed of.

## 3.2 Results and analysis

The questionnaire was filled in by the relevant experts of all piloting domains. Following are the comparative and qualitative analysis of their feedback, divided by sections.

**Security goals.** The first section investigated the employment of security mechanisms to address the desired security goals. As shown in Fig. 3, all security goals set to be addressed by the specifications have been a requirement that was also addressed by one or more of the pilots. One of the pilots, (eTendering) employed mechanisms for addressing almost all security goals, which was to some extent expected, considering that it was structurally the most complex and had to cope with all information states during its lifecycle.

<footnote n="4">⁴ http://tiny.cc/yjwfaz</footnote>
<figure><img src="image_4.png" /><figcaption>**Fig. 3.** Security goals addressed by the pilots</figcaption></figure>

Confidentiality and Integrity were addressed by almost all of the pilots, whereas the results for Availability reveal that further considerations are needed in this direction. On the one hand, assuring Availability of all resources and hardware, fault-tolerance and redundancy is country-dependent. However, considering the fact that Hardware, Software and Networks are among the security assets stated by the pilots, Availability is expected to be among the top security goals to be addressed. The fact that no pilot has reported consideration of Redundancy and Fault-tolerance, is thus of no surprise. At the same time, it reveals a need for better consideration and proper accounting for Availability as one of the major security goals.

**Information taxonomy.** Information in e-SENS is tackled in all states in its lifecycle: Creation, Transmission, Storage, Processing and Destruction. Some pilots did not employ mechanisms to handle information securely in every state (see **Fig. 4a**), but all pilots ensure secure transmission of information. However, dealing with information in a particular state is highly context-dependent. Thus, no claim can be made on whether some security mechanisms are lacking or if information is not handled securely. Secure processing and creation of information were addressed to a greater or lesser extent.

<figure><img src="image_5.png" /><figcaption>**Fig. 3.** a) The state in which Information is being dealt with; b) Entities concerned by the security mechanisms implemented in the pilots</figcaption></figure>

Variety of entities for which Information is the main asset are concerned in the implementation of security mechanisms (as shown in **Fig. 4b**). Software, Networks, Pro-
cesses and People are also major security assets, whereas Hardware is only rarely ad-
dressed. However, the number of security assets and the frequency of implementation
of certain security mechanism are of less importance; the impact of the particular asset
for the overall system and the impact of the failure of a certain security mechanism are
crucial. The choice of entities to be addressed by the security goals is both context- and
mechanism-dependent. However, as humans are at the core of all systems, it can be
observed that the human-factor is poorly addressed by the security mechanisms. This
is especially important if one considers that countermeasures can be legal, organiza-
tional and purely human-oriented. Next, broader analysis of this issue are presented.

**Countermeasures.** Regardless of whether a certain pilot implemented security mech-
anisms with a concrete threat-model in mind, countermeasures could still be in place
due to mere operational system requirements. The countermeasures' types investigated
here are: i) Technical; ii) Legal; iii) Organizational; and iv) Human-oriented. Technical
countermeasures that are widely employed by the pilots are encryption and authentica-
tion. They are complemented with legal countermeasures in the form of agree-
ments/contracts, whose type depends on the pilot's needs. Policies are the organiza-
tional countermeasures implemented, whereas audit was reported by only one of the
pilots (eConfirmation). Human-oriented countermeasures are largely lacking, with
'Motivation' and 'Operational guidelines' being the only ones considered.

The implementation of countermeasures is highly context-dependent. Not every pi-
lot has the same assets to secure or deals with the same risks. For e.g., whereas most
pilots employ only encryption and authentication as technical countermeasures, the
eHealth pilot also implements policy-based access control for authorization, and pa-
tient-informed consent to address Privacy. However, starting from the lowest level pos-
sible, training of both public administration, citizens and workers must be enforced,
since user knowledge and behavior are the first line of defense against cyber-threats.<fnref n="5" />

**Trust.** Trust mechanisms facilitate the accomplishment of Integrity and Accountability. Confidentiality, although mainly addressed through encryption, is also strengthened by trust in the underlying infrastructure. All pilots employ one or more types of trust mechanisms, depending on the needs of the intra-domain or the cross-domain trust establishment. Although the Trust Network PKI<fnref n="6" /> is the most widely employed BB, all of the Trust Establishment BBs are used by some of the pilots. One trust issue reported by the pilots is that self-signed certificates are still widely used. Although they may decrease the overall security risk of a transaction in some situations, self-signed certificates cannot be revoked, allowing an attacker with authorized access to monitor and inject data into a connection, or spoof an identity if a private key was compromised. This points to the need for adequate risk analysis, which was not done by any of the pilots.

Trust analysis does not only help in the consolidation of security policies across a
system architecture, but it points to the fact that trust in the overall architecture is as

<footnote n="5">⁵ ENISA guidelines (SO6) in D2: Human resources security</footnote>

<footnote n="6">⁶ PKI stands for Public Key Infrastructure</footnote>
important as securing the information that flows through that architecture. The presented methodology enables this kind of trust reasoning and can be used to assure the adopters of any of the architectural solutions of their desired trust properties.

**Security system lifecycle.** This section explored the general lines of development of the security mechanisms. In a way, it extracts the bigger picture of the security design and management of the system.

Most e-SENS pilots base the choice for employing trust and security mechanisms on an inherited infrastructure (from previous Large Scale Pilots<fnref n="7" />). The results are to a certain extent a testimony of the ability to adapt novel security mechanisms to earlier security infrastructures. This adaptability of security solutions is also an argument for the architecture sustainability with respect to the BBs' security capabilities. Therefore, the fact that all pilots claim low expectations for frequent mechanism updates comes as no surprise. In terms of stability of the security mechanisms, all security experts responded that small changes in the security mechanisms would not have a big impact on the remainder of the system. However, most of the pilots reported no redundancy considerations in the security mechanism design. This again points to the need for risk-modelling and analysis, and introduction to proper countermeasures during system design.

**Overall evaluation of the e-SENS security measures.** After performing the cybersecurity evaluation of all SATs, the overall e-SENS security measures have been evaluated and assigned a sophistication level according to ENISA guidelines. The security measures are grouped in three sophistication levels as shown in **Table 4**.

Each level corresponds to some criteria judging of its attainment. The results are backed by evidence gathered in support of the judgement. The levels are cumulative, so the evidence for attaining level 2 applies to level 1 as well.

<table><caption>**Table 4.** Evaluation of sophistication level of e-SENS security measures according to ENISA descriptions</caption><thead><tr><th rowspan="2">ENISA description of sophistication levels</th><th colspan="2">Assessment of the e-SENS security measures</th></tr><tr><th>Level Attained</th><th>Evidence</th></tr></thead><tbody><tr><td><p><em>Level 1 (basic):</em></p><ul><li>Basic security measures that could be implemented to reach the security objective.</li><li>Evidence for that.</li></ul></td><td>Yes</td><td>Basic security measures are in place - the arguments were detailed in the BB's security evaluation and the pilots security evaluation</td></tr></tbody></table>

<footnote n="7">⁷ EPSOS (eHealth), PEPPOL (eProcurement), E-CODEX (eJustice), to name a few</footnote>
<table><tr><td>Level 2 (industry standard):<br/>- Industry standard security measures to reach the objective and an ad-hoc review of the implementation, following changes or incidents.<br/>- Evidence for that.</td><td>Yes</td><td>Industry security measures are in place<br/>- demonstrated in the pilots security evaluation and in the assessment of technical maturity of the e-SENS RA's building blocks</td></tr><tr><td>Level 3 (state of the art):<br/>- State of the art (advanced) security measures, and continuous monitoring of implementation, structural review of implementation, taking into account changes, incidents, tests and exercises, to proactively improve their implementation.<br/>- Evidence for that.</td><td>Not Yet</td><td>Not all e-SENS BBs have reached full technical maturity and scalability readiness; no comprehensive documentation is provided to claim accounting for changes, incidents and tests to improve the implementation of the security measures.<br/>However, solid basis for reaching level 3 can be provided: the current analysis is a form of a structural review and a proactive step towards recommendations to improve the security measures implementation.</td></tr></table>

The possibility of e-SENS RA to be adapted to the domain needs and to evolve with the system speaks of its flexibility to retain the reached sophistication level. This wraps up the complementary view on the goal-based approach and provides the cybersecurity evaluation with operational recommendations for securing the e-SENS RA solutions.

## 3.3 Discussion

While not all pilots address all security goals or employ countermeasures, the fact that all security goals were addressed, information has been accounted for in all of its states, all entities were tackled by some of the security mechanisms and technical, legal, human and organizational countermeasures are in place, testifies that the e-SENS RA satisfies the cybersecurity requirements by the pilots. However, not all recommendations for a secure system operation and maintenance can and should be addressed by a single project; imposing technical, legal, and organizational requirements is dealt with on national or domain level. While desirable good practices may be part of its recommendations, mandatory security measures are not.

Complementing a reference architecture with a methodology to encompass the security goals from design time with tools to support the cybersecurity assessment is of paramount importance for meeting the regulatory requirements as well. Clearly, the mechanisms employed depend on the particular context and use case and cannot be joined by a universal security mechanism. The results from the questionnaire demonstrate that the generic security properties provided by the e-SENS RA are also reflected in the pilot implementations.

To validate the adoption of e-SENS building blocks, special events named connect-a-thons were organized within the eHealth pilot, where conformance and interoperability tests were performed assisted by tools<fnref n="8" /> and skilled personnel [12]. The secure and

<footnote n="8">⁸ The Gazelle test suite, http://gazelle.ihe.net</footnote>
successful cross-border exchange of patient summaries and ePrescriptions was simu-
lated among at least 4 countries. It is the first attempt to reuse this testing methodology
for architectural assets created outside the eHealth domain.

This cybersecurity analysis joins the benefits of a goal-based approach with the sys-
temic nature of a threat-view on security management. It also helps to organize the
security policies spread over multiple domains. Furthermore, it not only permits tracing
possible contradictory security policy statements, but facilitates the identification of
weak or omitted security policies as well.

4 Related work

The EU is making significant steps toward cross-border eServices interoperability and implementation. The 2018 edition of eGovernment summarizes related policies and activities in 34 countries and enlists cybersecurity as an emerging topic [14]. The NIS Directive aims at ensuring a high level of network and information security across Europe [15]. As a response to the directive requirements, ENISA, national governments and National Regulatory Authorities engaged in joint work in order to achieve harmonized implementation. Three non-binding technical documents were provided as guidance to the NRAs across EU member states [7], [16], [17]. The presented analysis is a contribution in similar direction and an effort to bridge technical solutions with regulatory policies and standardization.

There are approaches that cover one or more aspects addressed by our work [18], [19]. In addition, [20] describes a thorough process to include and evaluate security aspects in all stages of the Information System lifecycle: requirement elicitation, acquisition, design and implementation, operation and maintenance, and disposal. Although security evaluation is included in the process, it follows a threat-based approach and offers no evaluation framework or any reference or enterprise architecture the systems might conform to. Evaluating certain cybersecurity attributes of enterprise architectures was approached in [2], [3], which mainly rely on human effort. The same stands for addressing interoperability in enterprise architectures [21]. Zuccato et al. [22] provide a holistic account of “security requirements profiles” in an organization by assembling a set of "modular security safeguards". However, they are concerned only with the technical aspects and mainly serve the solution developers.

There is criticism about security design frameworks deemed to be too focused on the
technical aspects and falling short in detecting and addressing potential design conflicts
[23]. An example of this is a system that should implement both anonymity and audita-
bility. By joining the goal-based approach with a threat-view, the issue of contradictory
requirements in technology management through enterprise architectures is addressed
from design time. Finally, the generic framework presented here is easy to understand
by a non-technical person, while offering sufficient technical guidance for the
(cyber)security experts.
# 5 Conclusion and Future Work

Secure information exchange platforms are crucial to the correct functioning of the ser-
vices they support. The methodology presented here can be successfully applied for a
model-based evaluation in a practical setting. It bridges technical and business solutions
with the latest regulatory policies and frameworks. The employment of RMIAS in prac-
tice has led to a goal-based security analysis of each architecture construct, identifying
how the technical specifications associated with them contribute to meeting the security
goals. The empirical security evaluation showed that although the implementations
were able to address the security goals, additional availability measures, proper risk
analysis, and provision of human-oriented countermeasures require refinement of the
architecture to provide further tools to reach the security objectives.

Designing a methodology to analyze security measures provided by the implemented
security mechanisms and integrating the outcomes of such analysis into the specifica-
tions allows for a technical person to cope more easily with the dynamics of security
changes that a system may require. Furthermore, by enabling a non-technical person to
understand the needs for implementing a certain security measures and the implications
of not addressing it adds value in terms of usability of the system itself and for aligning
the managerial requirements with the technical possibilities that an architecture offers.

Although each e-SENS pilot performed the evaluation of the architecture via do-
main-specific methodologies (e.g., connect-a-thons in eHealth), we pursue two inde-
pendent approaches for the security assessment of the building blocks. Firstly, we plan
to evaluate the eHealth pilot architecture with a tool such as securiCAD<fnref n="9" />. Secondly,
we will formalize the conceptual framework of the methodology in order to enable a
semi-automatic solution architecture design and help the architect deal with the varia-
bility and optionality of the design choices. An immediate step towards the automation
of solution architecture design is thus the automation of the quality-attributes check.
One way to do that is by employing denotational semantics as the formal apparatus, but
other possibilities will also be tested. Therefore, an open-access implementation tool
will be created to allow reusability and testing of the methodology, and moreover, im-
plementation into real-world setting.

References

1. M. Korman, R. Lagerström, M. Välja, M. Ekstedt, and R. Blom, "Technology management through architecture reference models: A smart metering case," in *2016 Portland International Conference on Management of Engineering and Technology*, 2016, pp. 2338-2350.

2. T. Sommestad, M. Ekstedt, and H. Holm, "The Cyber Security Modeling Language: A Tool for Assessing the Vulnerability of Enterprise System Architectures," *IEEE Systems Journal*, vol. 7, no. 3, pp. 363-373, Sep. 2013.

3. H. Holm, K. Shahzad, M. Buschle, and M. Ekstedt, "P²CySeMoL: Predictive, Probabilistic Cyber Security Modeling Language," *IEEE Transactions on Dependable and Secure Computing*, vol. 12, no. 6, pp. 626-639, Nov. 2015.

<footnote n="9">⁹ https://www.foreseeti.com/community/</footnote>
4. E. Grandry and e-SENS Architecture team, "D6.7 e-SENS European Interoperability Reference Architecture." European Commission, 31-Mar-2017.

5. M. Masi, T. Pavleska, and H. Aranha, "Automating Smart Grid Solution Architecture Design," in *2018 IEEE International Conference on Communications, Control, and Computing Technologies for Smart Grids (SmartGridComm)*, 2018, pp. 1-6.

6. Y. Cherdantseva and J. Hilton, "A Reference Model of Information Assurance & Security," in *Proceedings of the 2013 International Conference on Availability, Reliability and Security*, Washington, DC, USA, 2013, pp. 546-555.

7. ENISA, "Technical Guideline on Minimum Security Measures — ENISA." 2014.

8. S. Röhrig, *Using Process Models to Analyse IT Security Requirements*. University of Zurich, 2003.

9. A. I. Anton, J. B. Earp, and A. Reese, "Analyzing Website privacy requirements using a privacy goal taxonomy," in *Proceedings IEEE Joint International Conference on Requirements Engineering*, 2002, pp. 23-31.

10. C. P. Pfleeger and S. L. Pfleeger, *Security in Computing (4th Edition)*. Upper Saddle River, NJ, USA: Prentice Hall PTR, 2006.

11. DG CONNECT, "Introduction to the Connecting Europe Facility eDelivery building block." European Commission, 2015.

12. eHDSI Business Analyst, "Non-repudiation mechanism - eHealth DSI Operations - CEF Digital," 2019. [Online]. [Accessed: 02-Aug-2019].

13. "What is eID," *CEF Digital*. [Online]. Available: https://ec.europa.eu/cefdigital/wiki/cefdigital/wiki/display/CEFDIGITAL/What+is+eID. [Accessed: 02-Aug-2019].

14. "Digital Government Factsheets - 2018 | Joinup." [Online]. Available: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/digital-government-factsheets-2018. [Accessed: 01-Aug-2019].

15. European Commission, "The Directive on security of network and information systems (NIS Directive)," *Digital Single Market*, 09-May-2017. [Online]. [Accessed: 31-Aug-2017].

16. ENISA, "Technical Guideline on Threats and Assets — ENISA." 14-Sep-2014.

17. ENISA, "Technical Guideline on Incident Reporting — ENISA." 24-Oct-2014.

18. "ISO/IEC/IEEE 24748-1:2018," *ISO*. [Online]. Available: http://www.iso.org/cms/ender/live/en/sites/isoorg/contents/data/standard/07/28/72896.html. [Accessed:01-Aug-2019].

19. P. Bowen, J. Hash, and M. Wilson, "SP 800-100. Information Security Handbook: A Guide for Managers," National Institute of Standards & Technology, Gaithersburg, MD, United States, 2006.

20. Cyber Security Agency of Singapore, "CSA Singapore Security-by-Design Framework v1.0." Cyber Security Agency, Singapore, 09-Nov-2017.

21. J. Ullberg, P. Johnson, and M. Buschle, "A language for interoperability modeling and prediction," *Computers in Industry*, vol. 63, no. 8, pp. 766-774, Oct. 2012.

22. A. Zuccato, N. Daniels, C. Jampathom, and M. Nilson, "Report: Modular Safeguards to Create Holistic Security Requirement Specifications for System of Systems," in *Engineering Secure Software and Systems*, 2010, pp. 218-230.

23. R. Mercuri, "Uncommon Criteria," *Commun. ACM*, vol. 45, no. 1, pp. 172-, Jan. 2002.