Introduction
This first section is aimed at establishing the context for the present deliverable, focused on the specification of BIECO’s overall architecture, including its components and the main interactions among them.
To this end, Section 1.1 starts by providing the background for this specification, positioning the present deliverable within the overarching activities of BIECO. Then, a brief discussion of related work is presented, with particular emphasis on existing standards and guidelines that are relevant reference points for the design and implementation of the overall BIECO framework.
1.1. Background
The advent of Industry 4.0 and the growing trend of digitalization have marked a shifting point in our societies, with the physical and digital worlds being more connected than ever before thanks to concepts such as the Internet of Things (IoT) and Cyber-Physical Systems (CPS).
This added level of connectivity between people, machines and systems have facilitated the emergence of new business models and services, with a clear move towards more autonomous and increasingly intelligent solutions.
Consequently, the cybersecurity and trust challenges have also been quickly increasing, with potential impact including not only the jeopardized safety of people and equipment and intellectual property, but also other economic impact such as lower quality or quantities of production, financial and legal implications as well as environmental damage or destruction.
In regard to the aspect of trust, this highly connected and collaborative environments of complex systems across entire supply chains have made it so that such ecosystems rely on the assumption that all of their components operate as expected, with a level of trust having to be established among them as a consequence.
BIECO aims to provide mechanisms to ensure that the behaviour exposed by an ecosystem participant (SW component, System) within a collaboration remains trustworthy in case of failures and remains robust and safe in the face of possible attacks or exploitations of vulnerabilities. This makes it possible to empower the resilience of systems that are part of an ecosystem against malicious attacks, displaying a trustworthy behaviour to the user (be it an interacting service or a human).
Since the malicious intent of potential attacks may be hidden in the smart agents and behaviours that comprise modern complex systems of systems, the assessment of the trustworthiness of a given ecosystem participant requires new platforms that cover multiple phases of the lifecycle, from design to runtime, with this being one of the main roles that BIECO intends to fulfil.
Therefore, the present document is a direct follow-up to Deliverable 2.3 [1], which provided the initial set of guidelines and specifications concerning the design and implementation of the BIECO solution for improving the resilience and trustworthiness of digital ecosystems. This follow-up consists in a maturation of the aforementioned concepts over the course of the following 12 months, which culminated in the finalized version of the architecture, detailed in terms of its components and respective interactions during both the design and runtime phases. This specification represents the main artifact and contribution that is produced by Task 2.3., marking the midpoint of the project.
A general depiction of the positioning and role of this deliverable within the context of BIECO is provided in Figure 1.
As previously mentioned, the high-level conceptual draft of the architecture provided in D2.3 consisted in the initial guideline for the early stages of BIECO, still at a low level of granularity. From there, this deliverable presents a more formalized and mature specification of the architecture, encompassing both lifecycle phases contemplated in the project, design and runtime, detailed in the form of component and sequence diagrams to guide the implementation and integration efforts for the second half of the project. Finally, in Work Package (WP) 8 the actual implementation of the BIECO platform and its integration with the remaining components takes place, representing the higher level of granularity among the activities planned for the project.
The remainder of this document is structured as follows: Section 1.2 presents a brief overview of related work, particularly in regard to existing standards and guidelines of relevance. Then, Section 2 summarizes the high-level conceptual view of the BIECO framework, followed by a recap of the goals and requirements identified within WP2. Afterwards, Section 3 overviews the BIECO architecture, with its specification being broken down into the Design Phase in Section 4 and Runtime Phase in Section 5. Lastly, a reference architecture instantiation example is provided in Section 6 based on the M18 pre-demonstration use case, finalizing with the conclusions and closing remarks in Section 7.
1.2. Related Work
While in the past the focus of cybersecurity was centred mostly on the defence of organizational perimeters, such as the protection against unauthorized access to private
computer networks (e.g., firewalls, malware protection, etc). Nowadays the increased connectivity brought about by the Industry 4.0 paradigm has forced organizations to rethink their cybersecurity strategy [2].
Advances in Information and Communication Technologies (ICT) have made it possible for Industry 4.0 systems and systems of systems to be highly connected and distributed, with a close link between the physical and the digital world. This makes it so that the topic of cybersecurity is now more critical than ever, with related technologies evolving at a rapid pace to match the increasing risk and threat levels of these systems, including for instance encryption and artificial intelligence-based approaches.
While the literature and regulatory bodies are not consensual in terms of a “one-size-fits all” architecture or solution that completely addresses all cybersecurity challenges, considerable effort has been made over the last years by official institutions to propose recommendations and best practices by using standards as references [3]. These include the International Organization for Standardization (ISO), the International Electrotechnical Commission (IEC) and the National Institute of Standards and Technology (NIST), some of which will be discussing in the coming subsections.
1.2.1. NIST Framework
The NIST has proposed a multi-platform framework for improving critical infrastructure cybersecurity [4], aimed at assisting organizations to manage and reduce cybersecurity risks. The framework core presents a set of functions that provide a strategic overview of the lifecycle for cybersecurity risk management, also discussed in the literature as the pillars of ICT cybersecurity [5], as depicted in Figure 2.
As per the framework, these functions are not intended to be a static, sequential methodology or lead to a static desired end state, but instead should be executed in parallel and continuously across the lifecycle of a system, in a way that is capable of addressing the dynamic cybersecurity risk. These five pillars or functions are adopted as guidelines for the BIECO solution, and can be defined as follows:
• Identify – Involves the understanding of the business context to manage cybersecurity risk in terms of systems, people, assets, data and capabilities. This relates to the activities developed particularly in WP3, WP6 and WP7, concerning vulnerability management, risk identification and the security context and claims.
• Protect – Entails the development of mitigation actions to limit or contain the impact of potential cybersecurity events. This aspect is covered in particular by
WP4 and WP6, regarding the study and development of resilience mechanisms and mitigation actions.
• Detect – Implement specific activities to identify the occurrence of relevant cybersecurity events. Here the main activities are encompassed within WP3 regarding vulnerability management and particularly WP5, addressing runtime auditing of ICT ecosystems.
• Respond – Implement measures to take action upon the detection of cybersecurity events.
• Recover – Ensure that appropriate measures are in place to maintain the resilience of the system and restore safe operational conditions, capabilities or services. Once again these last two points relate to WP5, as the Auditing Framework [6] enables the notification of alarms or triggering of mitigation actions according to the results from the complex event processing and the conformity monitoring supported by the predictive simulation.
In addition to this, other guidelines and recommendations have been put forth by different organizational bodies, some of which will be discussed in the upcoming subsections.
IACS automation solution security lifecycle as shown in Figure 3.
Figure 3 – ISA/IEC 62443 IACS Automation Solution Security Lifecycle (adapted from [8])
The different phases can be defined as follows:
- Specification – As mentioned before, it includes the identification of the system under consideration and the initial high-level cybersecurity risk assessment. The result is the specification of the target security levels used for the design phase.
- Design – This phase entails the detailed design of the system, including technical security measures based on the security level and the related organizational security measures.
- Implementation – At this stage the technical security measures specified in the cybersecurity requirements are implemented in the solution. The organizational security measures are developed so that they are available during the verification and & validation phase.
- Verification & Validation – During this part of the lifecycle the solution is tested to ensure the technical and organizational security measures meet the specified security and safety requirements. Some examples include vulnerability scans, intrusion detection tests and access control tests.
- Operation – The operation phase refers to placing the solution into service, and executing different security measures, which should be periodically reviewed and updated.
- Maintenance – Relates to the continuous monitoring of security threats and vulnerabilities during operation. Addressing such threats may require changes to the organizational or technical security measures of the IACS.
- Decommissioning – The decommissioning phase can be triggered by a maintenance activity (e.g., replaced a given hardware component) or by a major upgrade to the system. Regardless, it should be done in a way that the on-going operations are not compromised.
This is of particular relevance to BIECO, as it highlights the importance of addressing the entire lifecycle of a system or component, from its specification and design to its runtime operation with continuous monitoring until the eventual decommissioning.
2. BIECO Conceptual Framework Towards Security and Trust in ICT Ecosystems
The rationale behind BIECO’s concept is to deliver a framework for improving trust and overall security claims within ICT supply chains. These are complex ecosystems comprising several heterogeneous technologies, processes, actors (e.g., end-users, software or hardware providers and organizations) and resources, all of which generate or exchange data forming extremely complex information management systems.
Due to this, cybersecurity and integrity are particularly important aspects to take into account in this context, which need to be addressed with an integrative approach that contemplates the entire chain, as opposed to restraining it only to the individual components. In this direction, BIECO aims to deliver a holistic approach to building and validating methodologies and technologies tailored to foster security and trust within ICT ecosystems.
BIECO covers the different parts of the product lifecycle, from the design phase with its security assessment methodology, to the runtime with its auditing system. To facilitate the cooperation of these different components at each phase, the BIECO middleware acts as both a common channel for communication and its orchestrator, enabling the interoperability of the BIECO solution via the designed common interfaces. Dedicated communication channels can be setup with the initial assistance of the orchestrator, such as the case for the Auditing Framework and its probes, as explained later in this document, which also mitigates the risk of message overload. Finally, BIECO envisions its validation across three industrial use cases, one addressing a smart grid environment, another focused on an AI-based investment platform and the other dealing with a smart micro factory in a manufacturing setting. A smaller pre-demonstration scenario is also considered, as discussed in Section 6, which addresses an intralogistics use case with mobile robots and acts as a test bed and showcase of the early-stage developments of the project.
In an effort to keep the specification of the BIECO framework self-contained, this section briefly recaps the requirements specification outputs from D2.1[10] and D2.2 [11], framing their relevance and mapping in the context guiding and constraining the specification of the overall BIECO framework presented in this document.
During the initial definition of BIECO’s project requirements, documented in D2.1 [10], the following set of project-level goals were identified, taking into account the challenges typically associated with such complex ICT systems of systems:
- G1 – Providing a framework that will allow the reinforcement of trust in ICT supply chains
- G2 – Performing advanced vulnerability assessment over ICT supply chains
- G3 – Achieving resilience in ecosystems formed by unreliable components
- G4 – Extending auditing process to evaluate interconnected ICT systems
- G5 – Providing advanced risk analysis and mitigation strategies that support a view of the complete ICT supply-chain
- G6 – Performing evidence-based security assurance and a harmonized certification for ICT systems
- G7 – Industrial validation of BIECO’s framework within IoT ecosystems
While this deliverable is particularly related with G1, as it entails the specification of the overall BIECO Framework, it is ultimately tied with all of the listed goals since the framework should be defined in a way that facilitates the realization of the project’s aims. From these goals, a set of Functional Requirements (FR) were derived.
| Requirement | Rationale | Goals | WPs |
| FR1 – Real-time Monitoring | BIECO should be capable of performing real-time monitoring/auditing of the underlying systems or devices to detect deviations from the expected behaviour. | G1, G3, G4 | WP5 |
| FR2 – Adaptation | BIECO should be able to adapt the underlying system/component/device at runtime based on adequate mitigation strategies | G1, G3, G5 | WP5, WP6 |
| FR3 – Vulnerability Analysis | BIECO should enable the identification and/or forecasting of vulnerabilities in ICT systems through advance data analytics. | G1, G2, G3 | WP3 |
| FR4 – Simulation | BIECO should be capable of simulating the behaviour of underlying systems or components to self-check future failures or vulnerabilities. | G1, G2, G3 | WP4 |
| FR5 – Security evaluation | BIECO should be able capable to measure the security of a system in an objective way using empirical tools such as testing. | G1, G5, G6 | WP6, WP7 |
| FR6 – Security certification | BIECO should be able to generate a visual and dynamic security label as a result of the security certification process. | G1, G5, G6 | WP7 |
| FR7 – Security baseline | BIECO should base the security evaluation on standards and best practices, taking into account also the relevant regulation. | G1, G5, G6 | WP7 |
| FR8 – Behavioural profiles | BIECO should design a security behavioural profile as a result of the certification process. | G1, G5, G6 | WP7, WP6 |
These FRs are tied to a specific component or set of components encompassed within the BIECO framework, each tasked with realizing a specific function within the overall scope of the project. For this purpose, Sections 4 and 5 will detail the components contemplated within each of the lifecycle phases addressed by BIECO (design and runtime, respectively), linking each the presented components back to the FRs presented in Table 1.Consequently, it is of particular importance to also account for the defined NonFunctional Requirements (NFR), as these deal directly not with the functionalities of the system, but instead with how these functionalities should be carried out. These are vital to the specification of the BIECO framework, since such specification must be developed in a way that accounts for such constraints by design. This is evidenced by the fact that every single one of these requirements is associated with G1, which is directly related to the framework. Once more, the list of non-functional requirements is presented in bellow.
| Requirement | Rationale | Goals | WPs |
| NFR1 – Interoperability | Heterogeneous components of the BIECO ecosystem should be capable of cooperating and exchanging data using common representations and interfaces | G1 | WP3, WP4, WP5, WP7 |
| NFR2 – Scalability | BIECO solutions should be agile and dynamic, being as automated as possible. | G1 | WP6, WP7 |
| NFR3 – Modularity | BIECO solutions should be loosely coupled, allowing stakeholders to mix and match functionalities of the framework as needed. | G1 | WP2, Wp3, WP4, Wp5, WP7 |
| NFR4 – PrivacyPreserving | Measures should be taken to ensure that BIECO’s tools preserve the privacy of sensitive data (e.g., source code) of stakeholders. | G1, G2 | WP3 |
| NFR5 – Standardization | BIECO solutions should be based as much as possible on current standards. | G1, G5, G6 | WP7 |
Starting from NFR1, within BIECO the interoperability aspect is crucial since the large set of envision FRs will be fulfilled by several heterogeneous tools. These tools must not only be capable of exchanging data amongst themselves in a way that can be interpretable by all, but also ensuring that the interactions occur in the proper sequence and in a way that can later be extended to accommodate additional tools beyond the scope of the project. For this reason, the BIECO framework includes a key component, the BIECO Middleware, which will simultaneously act as the shared channel for communication and as its orchestrator, providing a common interface for BIECO’s components to interoperate.
Regarding NFR2, following the same principle the orchestrator will facilitate the inclusion, setup and automation of additional tools using pre-defined flows for each of the lifecycle phases addressed in BIECO.
Concerning NFR3 (modularity), BIECO presents a loosely coupled architecture, allowing stakeholders to choose which functionalities of BIECO should be deployed, enabling the adoption of either the full solution, or partial subsets of its functionalities. Such considerations are discussed in Sections 4.3.4 and 5.3.2.
In terms of NFR4 and the exchange of sensitive data, BIECO’s framework envisions the creation of a Data Management and Storage component, which will be divided into public and private access parts following adequate data management practices. Sensitive data will be stored privately with controlled access (secret key for each use case), being used mostly for the connection between the two contemplated lifecycle phases, as discussed in Section 3. Thus, sensitive data will be linked to the use cases and not made available for the general public. In cases where the data should not be stored due to privacy or intellectual property concerns, BIECO will enable the user to upload the data only for processing via the User Interface (UI) (e.g., such as the case for the vulnerability assessment), without it being persisted anywhere in the platform. Finally, in relation to NFR5, for the both the design of the BIECO architecture and the implementation of its components, existing standards and guidelines are being taken into account such as those described in Section 1.2, D2.2 [11] and D7.1 [7].
The BIECO Architecture
This section details the formalization of the overall BIECO architecture. It provides an overview of the BIECO components comprised along the contemplated lifecycle phases, namely design time and runtime. In addition to this, the bridge between the two phases is discussed, with reference to the components that enable such a link. Then, varied usage patterns for the BIECO framework are presented, differentiating between mode of operation and respective functionalities/limitations based on which components are deployed.
The architecture is depicted using component diagrams, loosely based on the Unified Modelling Language (UML) notation. Such diagrams are “architectural” in nature, forming the model of architecture space, incorporating the needs and limitations of the organization placed on the system [12]. To facilitate the understanding of these diagrams, some key definitions of their elements are provided:
- Component: An entity required to execute a stereotype function. A component provides and consumes behaviour through interfaces, as well as through other components.
- Node: Represents hardware or software objects, which are of a higher level than components.
- Port: Specifies a separate interaction point between the component and the environment. Represented with a filled square symbol.
- Package: Groups together multiple elements of the system. Just as file folders group together multiple sheets, packages can be drawn around several components.
- Usage Dependency: A usage dependency is relationship which one element requires another element for its full implementation. It is shown as a dashed arrow with a <<use>> keyword. The arrowhead points from the dependent component to the one of which it is dependent.
- Required Interface: Represented by a straight line from the component with a half circle. These symbols represent the interfaces where a component requires information in order to properly perform its role.
- Provided Interface: Depicted as a straight line from the component with a circle. This symbol represents the interfaces where a component produces information used by the required interface of another component.
