Key components of SPHINX Architectrure building blocks Part III
Continue from Part II
In SPHINX building blocks, the technical consortium members are joining efforts to deliver twenty-one key components according to their expertise. Below, the components are presented:
A Sandbox provides a safe and isolated testing environment where components can be deployed without compromising any of the other services. It enables users to run programs or execute files without affecting the main application, system or platform on which they run. Software developers can use sandboxes to test new programming code. Cyber security professionals can use sandboxes to test potentially malicious software. Sandboxes are also used to safely execute malicious code to avoid harming the device on which the code is running, the network or other connected devices. The outcome is a secure way of assessing new components or tools in terms of security.
The Sandbox, which is led by PDMFC, is an important component for integrating the Automated Cyber Security Certification in the SPHINX Platform, mitigating potential negative effects on the main functionalities of the system and IT infrastructure. More importantly, sandboxing is mandatory for performing real time and live automated tests on the actual infrastructure, minimising the possibility for uncontrolled behaviour and prohibiting any negative impacts which affect the main system. The main purpose of the sandbox is to enable users to automate the sample submission process; completely analyse any threat; and quickly act to protect sensitive data.
Knowledge Base (KB)
Towards collecting and forming knowledge, led by FINT, the SPHINX Knowledge Base (KB) collects anonymised security intelligence and insights from external web sources (for this purpose, autonomous agents will search and mine web sources), as well as from SPHINX components (e.g. SPHINX MLID and HP). This information is translated into security rules and shared among the network by updating the respective advanced threats registries. The KB gathers security incentives for a collective wisdom creation, as well as interconnects/ integrates with third parties threat intelligence. These third parties threat intelligence repositories are included (optionally) in the SPHINX installations and provide insights on occurred cyber-attacks (no specific user or device data, including origin are transmitted, only the sequence and shape of the attacks).
Blockchain-based Threat Registry (BBTR)
Led by TECNALIA, the Blockchain-based Threat Registry (BBTR) component acts as a background infrastructure which safely stores different logs from different sources such as hospitals, care centres, pharmacies, medical devices and patients. It can be used to store any kind of interesting information, such as critical logs or thread information. The main advantage in using Blockchain is to have a distributed ledger with unalterable information, synchronised between all parties.
Cyber Security Toolbox (CST)
The SPHINX Cyber Security Toolbox (CST) component is led by HMU and enables SPHINX users to select the security services that best match their needs, to use within the SPHINX ecosystem. It allows users to plug cyber security services into their existing connectivity services and configure/adapt them according to their security needs. In this respect, and upon receiving the users’ requests, CST jointly examines the available infrastructure resources and the available security functions/services that are part of the Toolbox and produces an indicative list of the appropriate technical offerings. To achieve this, the Knowledge Base repository is utilised for the drawing of good practices and lessons learned from past experiences.
Application Programming Interface for Third Parties (S-API)
The SPHINX Application Programming Interface (API) for Third Parties (S-API) enable third-party healthcare solution providers to access and interact with the SPHINX Platform and its components. The component is led by EDGE. Subject to authentication and using end-to-end encryption, S-API exposes advanced cyber security functionalities implemented by SPHINX components, such as device/application certification, threat registry notification and anomaly detection.
Service Manager (SM)
The SPHINX Service Manager (SM) component is led by ICOM and keeps the registry of services managing information such as the service name, description, URL, version, call method, exceptions, security, and permissions based on role management. Different roles will be supported: for example, there would be a role name “admin” that manages the users by creating, updating and deleting users and their access rights to services and resources; the “admin” can also define a service by providing all the necessary information (service name, description, URL, version) and this information (the service definition) is stored in the services repository of the SM component.
Common Integration Platform (CIP)
Also led by ICOM, the SPHINX Common Integration Platform (CIP) provides a data and processes integration framework and infrastructure for all SPHINX components and services.
The CIP is built upon the basic concepts of virtualisation, containers and Virtual Machines (VMs), therefore providing inherent sandboxing capabilities. Containers use a common kernel for process level isolation and VMs through hardware level abstraction. Containerisation allows to package applications in containers for secure and isolated execution, making them portable between different computing environments. A container packages up code, runtime and all its dependencies so that the application runs quickly and reliably independently of the underlying hardware and operating system. The encapsulation of each software component in a container image allows developers to separate tasks into microservices (standalone applications that collaborate with each other) thus enabling independent maintenance. Upscaling and update.
Each SPHINX component is deployed independently on the CIP component in the form of a docker container. Docker containers are deployed on VMs so that microservices are isolated from each other but also grouped inside of the VM host.
More information about the key components of SPHINX’s architecture building blocks can be found at Deliverable 2.6 that is publicly available here.