Changes from D3. 1 Since D3.1, there have been some minor adjustments, primarily resulting from the integration with the dashboard and the introduction of multi-tenancy support. SCs can be designated as private if they are intended for internal use within the SC developer’s organisation. When marked as private, the onboarding process is initiated automatically during registration; while, for public SCs, onboarding is initiated upon an authenticated dashboard user’s subscription or purchase. Furthermore, authenticated users have the ability to deploy or initiate the onboarding process for a SC through the SCC REST Application Programming Interface (API). To accommodate these changes, modifications to the authentication mechanism and SCC database schema have been implemented.
Changes from D3. 1 The design of the framework regarding the risk assessment and calculation has not changed. The main difference with the previous version is the definition and development of the interfaces used from the external components.
Changes from D3. 1 Some specifications were added:
Changes from D3. 1 A number of specifications have been reviewed or dropped. Regarding the reviewed ones, the changes are listed below: ● SO_S2 (related to R1.3.2) now indicates that the SO receives a configuration action, not the Medium Level Security Policy Language (MSPL) itself. Instead, the logic that would traditionally be obtained after translating the MSPL to Low Level Security Policy Language (LSPL) is covered inside of each SC and tailored to its specific behaviour. ● All specifications had the relation to the CFG module removed because its objective is to allow exposing and modifying general system-wide information rather than the specific information related to SCs or infrastructures. The exceptions to this review process are SO_S8 (related to R1.3.15); and SO_S10 (related to R1.4.1), which was already not related to the module in the prior iteration because the interaction with the attestation was already expected to differ slightly with respect to other components. On the other hand, other specifications were removed: ● SO_S3 (related to R1.3.7) since, once all SCs are deployed via Docker runtime (with Open Container Initiative or OCI images), the Container Runtime Interface or CRI takes care of properly handling all the dependencies (the image). This is not the case for QEMU images used by OpenStack, which must be previously uploaded to the VIM and are not fetched on demand by the CRI. Therefore, this requirement (and its specification) is no longer relevant. ● SO_S9 (related to R1.3.16) with the usage of SDN technology to programmatically configure the networks that interconnect the infrastructures. The requirement was discarded, considering the needs of the infrastructure and the setup of the different delivery modes. Finally, a potential requirement to be dropped is R1.3.16 (related to SO_S9), where both the SO and the SCHI were expected to fulfil it.
Changes from D3. 1 The following list contains a set of minor changes that do not affect the scope of the requirements.
Changes from D3. 1 There are no perceived changes in the requirements for RAF with respect to those introduced in D3.1.
Changes from D3. 1 The SCs have finally been developed as Docker images since the standard VIM selected for the project is Kubernetes (K8s) [4]. K8s supports the different needs of the delivery modes, adapting it to the specific requirements in each environment. The base SC image incorporates an Ubuntu 20.04 version (to be aligned with the particular software requirements) with the security service software installed there. Besides, the SC image contains the necessary configurations for its correct deployment. All SC images are uploaded to Dockerhub [5], the official public repository where many developers contribute their images. Juju is the technology used to encapsulate the SC image in a Juju charm (through a Python library). The juju charm comprises two pods (i.e. the logical wrapper entity for a container): one containing the SC image (deployed with the Podspec mechanism) and the other containing the Juju operator. The latter pod is used to trigger the day0, day1 and day2 actions into the SC image, used to reconfigure the SC in real-time. The Juju charm is packaged using the charmcraft command, which creates a .charm file containing its programming logic. To allow more complex deployments, the Juju charm can also be composed by a Helm chart and a Juju operator. The Helm chart is a K8s-related technology that offers a way to package a collection of K8s resources. Adopting this technology improves the adaptability of SC developments and the possible implementation of any security service. In practice, this type of SC is implemented differently because the Helm chart needs to be defined and, in this case, the Juju charm is implemented as a proxy to communicate with the Helm chart deployment. However, this is transparent to the final user since it continues to use the day0, day1 and day2 actions mechanism to interact with the SC. The Helm chart technology has allowed the incorporation of the SIEM SC since it encompasses different Docker images and complex interactions between them.
Changes from D3. 1 On the one hand, the adopted technologies for the development and deployment of SO were revised and some of them incurred into changes. In this regard, Python3 is still in use to develop all the logic in the modules. Flask [11] and FastAPI [12] are both used: Flask is used for exposing the interfaces of the internal modules, whilst FastAPI (with uvicorn [13]) is used to expose and document all the interfaces supported by the API module, which is exposed to the PALANTIR clients. Compared to FastAPI, Flask provides non-production servers, which may be acceptable as long as these are internal; and also lacks the user- friendly interface to run the different actions that OpenAPI/Swagger [14] provides. Therefore, FastAPI is favoured for the external API module. Also, more technical documentation is provided (for the PALANTIR operator) in Markdown [15] files. Regarding configuration, whilst JSON and YAML were initially explored, YAML is widely favoured and is the approach finally followed by SO to host the static configuration files. As per accepted mimetypes, the default accepted content type is JSON, whereas explicit YAML requests shall also be served. As per the options to deploy SO itself, D3.1 initially proposed venv [16], Docker [17] (via docker- compose [18]) and Kubernetes [19]. In the end, the deployment provides scripts that rely on Docker (through docker-compose). The original venv-based deployments are available, but not further extended or adapted. Regarding Kubernetes, the prospecting efforts were not continued within the project and are enhancements left to the continued development of the SO beyond the project. On the other hand, and regarding the integration of SO with the infrastructure (SCHI) and its deployment of the SC instances, OpenStack [20] was dropped since D3.1 in favour of Kubernetes as the default VIM for the Network Function Virtualisation (NFV) architecture. This fact impacts the SO in multiple workflows, specifically those related to (i) the onboarding of packages and ancillary information, which is now simplified by the usage of Docker images as these are automatically managed by the CRI; (ii) the different means to extract runtime information related to the properties of the running SC instance and the image containing the logic, which are needed for the attestation process; (iii) similarly, the extraction of infrastructure-related information; and (iv) the monitoring of metrics related to the running SC instances, which initi...
Changes from D3. 1 The authentication between SCC and the dashboard is now established via Keycloak [22]. Furthermore, SCs can be marked as private, where a private SC is meant to be used only inside the SC developer organisation. Therefore, SCC has some new REST endpoints for the dashboard users to consume. A new endpoint to trigger the onboarding process has been added, along with an endpoint to trigger the deployment of a SC. Also, search functionalities of the SCC API are now restricted based on the user organisation who consumes the API. Regarding the SCC’s database (MongoDB), changes were made to match the multi-tenancy requirements. During the registration of a new SC, the related module of the SCC (in this case, SCC-R), is responsible for storing the SC developer’s details; where a tenant or organisation ID is now stored in the DB, as this is mandatory for proper integration between the SCC and the SM and Billing Dashboard framework of WP4.
Changes from D3. 1 The previous version of RAF was a LimeSurvey-based [25] application. In this version, the framework was rebuilt with custom Python code and well-known Python modules. As mentioned, the usage of the Flask module gives a lot of flexibility regarding the communication with other components. Since LimeSurvey had its own way to store information, a MongoDB database was now required to allow persisting data; and suitable connectors had to be developed for it. Finally, the current version of RAF is a very lightweight application which can be either deployed as a Docker container or as a Kubernetes pod.
