The H2020 PALANTIR project aims at delivering a Security-as-a-Service solution to SMEs and microenterprises via the exploitation of containerised Network Functions. However, these functions are conceived by third-party developers and can also be deployed in untrustworthy virtualisation layers, depending on the subscribed delivery model. Therefore, they cannot be trusted and require a stringent monitoring to ensure their harmlessness, as well as adequate measures to remediate any nefarious activities. This paper justifies, details and evaluates a architecture supporting C&ESAR'22: Computer & Electronics Security Application Rendezvous, Nov. 15-16, 2022, Rennes, France
periodically attests the service and infrastructure’s components for signs of compromise by implementing the Trusted Computing paradigm. Verification addresses the firmware, OS and software using UEFI measured boot and Linux Integrity Measurement Architecture, extended to support containerised application attestation. Mitigation actions are supervised by the Recovery Service and the Security Orchestrator based on OSM to, respectively, determine the adequate remediation actions from a recovery policy and enforce them down to the lower layers of the infrastructure through local authenticated enablers. We detail an implementation prototype serving a baseline for quantitative evaluation of our work.
The recent years have witnessed a flourishing diversity of cyber-attacks and techniques jeopardising
organisation's activity and assets. While large companies and public bodies promptly reacted by
acquiring necessary skills, processes and tooling to handle such risks, SMEs and microenterprises are
facing fierce obstacles due to their limited investment capabilities and manpower to allocate. For those
actors, contracting a Managed Security Service Provider (MSSP) has become a practical option to
delegate the prevention and the management of cybersecurity incidents. In this context, H2020
PALANTIR project [
Jacquin);
2022 Copyright for this paper by its authors. mitigation of malevolent activities on the customer's premise. To ensure PALANTIR extensibility, they are proposed in an as-a-service market open to contributions from third-party developers.
However, if not properly controlled, inviting external contributions exposes PALANTIR platform
to the risk of being weaponised against their customers: not only a security service could deliberately
be converted into a threat vector (e.g. disguised malware), but developed appliances remain subject to
unintended software flaws likely to be exploited by a malevolent actor. These defects can appear at
design time as a result of limited quality assurance and secured development practices, but also during
their operation, as software vulnerabilities are discovered. Another risk item is induced by the
PALANTIR infrastructure hosting the deployed security enablers: as they encompass distributed
resources hosted by both the MSSP (e.g. cloud and edge environments) and the customers (e.g.
customer premise equipment), they represent attractive targets. This is so since their disruption will
impact the reliability of deployed security enablers (as stated by governmental cybersecurity agencies
[
Given the prevalence of the MSSP concept in the delivery models offered by PALANTIR and the potential distribution of some elements in the stack, it is necessary to define a trust model that can assess the integrity level of any asset under the PALANTIR protection, disregarding the location of its deployment. The effective enforcement of such model is also contemplated, considering security orchestration techniques. This paper delves into the main question on how to elaborate a trust model for a distributed MSSP. The contributions of this work span (i) the definition of the trust model for an MSSP deployment, (ii) the assessment strategies that ensure continued integrity of the assets, (iii) the orchestration techniques and interactions in place to enforce these strategies, and finally details (iv) the implementation and evaluation of the technical stack contributing to the fulfilment of the integrity assessment in the ZTA architecture within the project.
The remainder of this paper is organised as follows: Section 2 discusses previous trust assessment research initiatives in the cloud-to-edge continuum, Section 3 comprehensively exposes the foundations of PALANTIR's ZTA architecture. We present our implementation and evaluation work in Section 4. Section 5 introduces the current limitations of our approach and proposes several options to tackle them. Finally, Section 6 concludes this paper and provides paths for future work.
The management of trust in distributed environments has been already largely explored in the
literature. Specifically, the software network community has been confronted early to the involvement
of multiple parties sharing the same infrastructure with possible competing objectives. For instance, the
European Telecommunications Standards Institute (ETSI) has published a threat analysis [
At the scale of a single node in distributed environment, virtualisation technologies can play a key
role to maintain trust through resource isolation. In [
Since 2010 [
PALANTIR envisions delivering a SecaaS platform to enable a service provider to oversee the security of the subscribers' assets. Security is enacted by granular enablers, i.e. security capabilities (SCs), deployed on an infrastructure under custody of a contracted provider. The SCs are conceived by third-party developers and made available through a marketplace. We propose the following threat model and assume the following actors and behaviours:
The PALANTIR provider and its operators can be trusted: they actively contribute to the security of the platform by applying proactively and reactively mitigations covering the complete spectrum of identified threats. This assertion is acceptable since the provider is the main beneficiary of the platform exploitation whose economic position and reputation are at stake. Specifically, we consider it is enforcing the necessary measures to protect the platform against both external and insider threats. Thus, we assume the platform and its infrastructure are part of the trusted computing base and can confidently support the features needed to maintain the whole deployment in a secured state while offering no exposure to an attacker for exploitation.
The infrastructure provider is deemed semi-honest: this actor applies protective measures when contractually obliged and audited but will not necessarily act beyond this scope. In fact, the infrastructure servicing is covered by agreements guaranteeing the level of service. Yet, the PALANTIR provider has no control over the contractor personal and cannot prevent an insider malicious actor. Moreover, as public hosting solutions are typically multi-tenant, the PALANTIR provider has no option to prevent an adversary from using this service and attacking other tenants or the infrastructure. An attacker can therefore target SC instances by tampering the infrastructure layer as (i) an insider of the provider company or as (ii) another subscriber given access to the same infrastructure.
The SC developer is also considered as semi-honest. Albeit producing security services to gain a revenue, the PALANTIR provider cannot assess the compliances with secure development practices. This implicates the software may contain flaws susceptible to be exploited. Furthermore, these vulnerabilities may stem from introduced dependencies carrying their own flaws. Therefore, the management of the supply chain by the involved developers represents risk factors. In this situation, an attacker can act as a neglectful developer introducing flaws by deficient quality evaluation, or as an actor of the supply chain inserting vulnerable code in the designed SCs, jeopardising their operation.
The subscriber, its collaborators and assets are inherently of lesser trust, as they request the protection services and lack the necessary tooling and practices to prevent or counteract cyberattacks on their own. When being subscribers to a MSSP solution, they may choose not to apply for a fullfledged protection for their IT (e.g. due to budget constraints), maintaining a vulnerable surface area. They represent common targets for threat actors, seeking to access their assets, or to rebound over SCs instances to target the MSSP.
In this context, SCs will seek to access resources on the customer information system and their hosting infrastructure while not being trustable due to their design and exposure. Our approach reverses the traditional use case of ZTA and proposes to entangle ZT principles with the management of SCs instead of the users: their instances and communication are scrutinised to evaluate their security postures and the PALANTIR platform acts as a mediation layer for their interaction with the customer resources.
To handle those prerequisites, the PALANTIR project focuses on the seven tenets on ZTA proposed
by NIST in the standard SP 800-207 [
The Trust, Attestation and Recovery (TAR) component continuously monitors the infrastructure and SCs to detect signs of attacks or erroneous behaviour. The TAR is also leveraged by the Security Orchestrator to ensure no untrusted node or capability is used to enforce the PALANTIR SecaaS solution. The TAR comprises the Attestation Engine (AE) and the Recovery Service (RS). The AE carries out the remote attestation of the nodes and SCs. The RS supervises remediation procedures that unify, correlate and automate event handling across the end-to-end physical and virtual infrastructure.
The Security Orchestrator (SO) subcomponent controls the lifecycle of the SC instances and provides context information about their static and runtime data. It ensures their placement, initial deployment setup, configuration and deallocation based on the customer requests and subscriptions. It also serves as the enforcer for countering the activity of compromised resources, thanks to the deployment and configuration of specific capabilities that fulfil the mitigation decisions from the RS.
The Security Capability Hosting Infrastructure (SCHI) represents the set of assets deployed in the PALANTIR platform (physical nodes provided by the infrastructure provider and SC instances running on them) that need to be protected through the ZT security model. The AE is responsible of continuously monitoring the integrity status of all the components in the SCHI, thus verifying that their security posture has not been compromised. When the AE detects an integrity failure, it notifies this event to the RS, which will enforce a suitable remediation in order to recover the security posture of the infrastructure.
3.3.
Managing the lifecycle and configuration of the security capabilities across different infrastructures is key to offer an automated manner of applying specific decisions, such as the enforcement of specific actions or configurations. SO provides the intermediate orchestration logic that receives the decisions to enforce on the running SCs. To do so, it is first contacted by the upper decision-taking logic provided by RS. Then, the SO coordinates with a third-party Management and Orchestration Software (MANO) named OSM (Open Source MANO) to instantiate the SCs as containers on the SCHI, as well as configure them. The configuration process emits adequate action requests to the SC endpoints, which have the logic to interpret and ultimately apply the action. Besides the instantiation and configuration features, the SO facilitates specific decision enforcement, as well as overseeing and exposing the behaviour of the infrastructure (SCHI) and the SC instances through its multi-layer monitoring; whose values can be used to assess the current status and complement the decision enforcement. These values come from the (i) container runtime and from (ii) the running SC instances themselves, both running on the SCHI. Specifically, and in order to identify the specific nodes subject to integrity measurement (described below), the AE uses a subset of data from (i); whilst other architectural components can request custom measurements from (ii).
At the initial attestation, right after receiving a request to deploy a specific SC, the SO fetches a subset of runtime data from the infrastructure and feeds it to the AE, which in turn performs the integrity check. If the attestation fails, the SO allows a set of actions that can alleviate the risk introduced by the potentially compromised SC instance (i.e. deployment, termination, or specific actions to each SC) and actions to restore the security posture (e.g. redeployment of an equivalent SC). This process also takes place during the periodic attestation of the SC instance, throughout its lifetime; where the AE continuously compares the reference measurements.
The ZT paradigm requires securing communications disregarding the network location. This also applies to the interfaces used by OSM and SO to communicate with the SCs that run on the SCHI; as these require mutual authentication, authorisation, and encrypted communication channels. The following ETSI NFV-compliant interfaces are secured at the SC or SCHI level, respectively: (i) between the VNF Manager (VNFM) and the NFs (Ve-Vnfm-em in ETSI terminology) to be configured through actions; and (ii) between the NFV MANO with the SCHI (Or-Vi in ETSI terminology) to manage the virtual resources subject to orchestration.
3.4.
The AE uses the Trusted Computing paradigm to continuously monitor SCHI, along with new methods to perform hardware attestation, runtime monitoring and containerised workload attestation. The AE follows the TCG specification to comply with the ZTA foundation; applying the TPM 2.0 Keys for Device Identity and Attestation standard when creating cryptographic keys and certificates used to perform attestation (Initial Attestation Key – IAK) or authentication (Initial Device IDentity – IDevID). The IDevID certificate is signed by the platform manufacturer, and it is complemented by an infrastructure-provided Local Device IDentity (LDevID) that cryptographically identifies the platform’s deployment.
The AE also leverages TCG Platform Certificates, issued during manufacturing to establish an
authenticated baseline for the hardware when it is first registered with the AE. A hardware measurement
capability is added through hardware fingerprinting in UEFI. In the current implementation of the AE,
UEFI fingerprints platform hardware by reading serial numbers from the devices including DIMMS,
PCIe cards and power supplies. This ensures that the hardware components have not been changed
since manufacture – unless an authorised hardware modification happened. In the near future, with the
adoption of the Security Protocols and Data Models (SPDM) [
While Trusted Computing mainly focuses on boot- and load-time measurement, the AE also supports
runtime verification. The Distributed Intrusion Monitoring Engine (DIME) [
The Remote Attestation based on TCG's principles is a well-established process for attesting physical nodes, yet it presents several challenges to attest virtual entities. In PALANTIR, the SCs are deployed as containers, following the current trend of lightweight virtualisation techniques, which offer considerable advantages in the management of microservices and guarantee near bare-metal performance. In order to create an attestation solution covering all layers of the SCHI, it has been necessary to tackle the remote attestation of containers, a problem still open for the scientific community. Our solution allows attesting each SC deployed on the SCHI and its host system without depending on specific container runtimes since it relies on properties owned by the containerised processes, which are valid for several containerisation technologies currently in use. Moreover, the solution complies with TCG guidelines as it is based on the TPM chip and the Integrity Measurement Architecture (IMA) module of the Linux kernel and is highly scalable since it does not limit the number of SCs to concurrently run on a platform. We integrated this solution into the PALANTIR AE which, together with the hardware, firmware and runtime attestation techniques presented above, provides an attestation solution capable of monitoring the entire software stack of a node, thus ensuring the security posture of all assets that are part of the PALANTIR infrastructure.
4. 4.1.
Implementation: The AE keeps monitoring agents distributed throughout the SCHI to assess the trustworthiness of the system. Each monitored node in SCHI hosts an Attestation Agent that is responsible for forwarding attestation information and alerts used by the AE. For example, it extracts the measurements stored in the TPM, signed with a TPM attestation key, and sends them to the AE used to compare against known baseline values. When new SC packages and images are made accessible to the PALANTIR platform, these values are automatically generated by a Reference Measurement plugin within the SO.
The AE provides continuous verification of hardware, firmware, OS, and workload from initialisation and through operation. The verification is based on the principle to build a secure chain of trust based on integrity measurements starting from the hardware root of trust which is a BMC in a server. The BMC Root of Trust provides the initial assurance that the platform starts in a known-good state. It is then followed by firmware integrity measurement leveraging the Measured Boot feature of UEFI and the bootloaders (e.g. Shim, Grub2). Each component, including the Linux kernel, is measured to create a chain of measurements, which are recorded in tamper proof storage, provided by the TPM. The measurements extension in the TPM provides a way to authenticate the chain of measurements when the AE verifies the state of the server. There are malwares that are known to disable security services such as secure boot to maintain persistence in the compromised nodes. A malware can extend new measurements in the TPM but cannot remove its measurement. Since each measurement is recorded and verified, such attacks can be detected by AE during platform initialisation.
The Linux kernel provides the IMA module in order to extend the chain of trust after the boot phase, up to the application layer. IMA implements the Measured Boot principles by making measurements on the dynamic executable content (applications and kernel modules) and the configuration files loaded at runtime; this allows the AE not only to verify that the platform booted in a trusted way, but also that all the applications and kernel modules loaded at runtime are trusted. The IMA module stores the sequence of the measurement events in a measurement list maintained in the kernel memory.
The AE Agent sends the IMA measurement log to the AE, together with the measurement aggregates signed by the TPM, at each attestation cycle. This allows the AE to determine the integrity level of each SCHI node at runtime; for example, if the AE detects a software component on a node that is not present in the whitelist for that node, or if the measurement of a component does not match its expected reference value provided by the SO, then the AE will mark the node as untrusted and will notify the RS, which is in charge to select the appropriate remediation actions that will be enforced by the SO (e.g. ring-fencing the compromised node, removing it from the cluster, applying security patches).
Our goal is to make the AE capable of attesting containers individually in order to identify any compromised SC; this allows to stop only the untrusted SC and to replace it with a new instance of an equivalent SC without the need to restart the entire platform, thus avoiding the disruption of the security service provided by uncompromised SCs. Containers are processes running on the host system: this means that the measurement events they generate are detected by the IMA module in the same way as those triggered by non-containerised processes and are stored all together in the same measurement log. This implies that, to attest containers individually, the AE should be able to determine if a given measurement event of the IMA measurement log belongs to a container or to the host system and, in the former, to which specific container it is associated. However, the built-in templates provided by the IMA module do not contain fields that allow to make this kind of distinction.
To overcome this issue, we defined and integrated in the kernel of the SCHI nodes a new IMA template that enables the attestation of individual containers; this template, in addition to the fields provided by the default template (i.e. the digest of the file content and the file path-name), provides other metadata that take into account some properties of the process triggering the measurement event, in particular its control groups and the list of its dependencies: • the list of dependencies field allows the AE to establish with certainty whether an entry of the measurement log was generated by a container or by the host system; and this is because, if the measurement event is related to a container, then the shim process that manages the execution of the container is always present in the dependencies field, otherwise the AE would attribute the measurement event to the host system; • if the entry belongs to a container, the control group field allows the AE to attribute the measurement to a specific container, and therefore to a particular SC, the measure has to be attributed; in fact, if the process that generates the measurement event runs in a container, this field contains the full-identifier of that container, allowing the AE to associate the measurements with the container.
In this way, the AE, by checking the IMA measurement log, can continuously monitor all the executable code and configuration files that are loaded into a specific SC at runtime and promptly react as soon as a measurement mismatch is detected, informing the RS on the integrity failure related to the SC.
Testbed: To test the functionality and performance of the AE, two test benches were created: one to evaluate the attestation capability of hardware, firmware, kernel runtime, and host system (i.e. the PALANTIR infrastructure), and a second one to test the integration of all the components of the PALANTIR project used in this work to evaluate the SC attestation capability. The first testbed is set up to evaluate the AE with one monitored node. Table 1 presents the testing environment used for the evaluation of the AE and AE agent in the infrastructure attestation use case.
8GB of RAM, 60 GB of HDD OpenSUSE Leap 15.3 HPE AE package for openSUSE_Leap15.3
The second testbed is configured to monitor SCs deployed on a single physical node, which is one of the worker nodes in the SO-managed Kubernetes cluster. The characteristics of the nodes used to test the AE's SCs attestation capability are listed in Table 2.
The AE has been configured acknowledging a real operational environment of having fixed period of attestation cycle. The attestation cycle for this evaluation is set to 10 minutes. To evaluate the infrastructure OS verification by the AE, a bash script has been designed to execute an attack on the monitored node on a random time (in the 2 to 8 minutes interval) between an attestation cycle. The host is forced to reboot each time the attack is detected to revert the attack. A minimum wait of 2 minutes is enforced before the next attack is executed to ensure that an initial attestation has been performed after the reboot. When the attack is detected immediately in the next attestation cycle and the attestation result is logged to measure the mean time of detection for the compromised node. For the infrastructure node attestation, a script is executed to make changes in hardware and firmware. In order for these changes to take effect, a reboot of the system is required. Once the machine is up, an attestation is performed on the monitored node which detects any sign of compromise in the machine. Finally, in order to evaluate SC attestation, a malicious insider actor compromising a SC has been simulated; as soon as the malware injected in the SC is executed, the attack is detected at the next attestation cycle.
Evaluation: The performance evaluation of the AE focused on the time taken by the AE to detect a compromise. The test scenarios for AE have been designed according to the attestation capabilities of the AE, extensively covering the system stack of SCHI to detect integrity fault. An attack has been simulated to trigger each attestation capability and the mean time to detect compromise was evaluated on the average from about 100 to 300 attestations performed for each set of experiments, in order to get statistically meaningful results. As for the SC attestation capability, the values have been acquired as the number of SCs instantiated on the node increases, starting from 1 SC up to a deployment scenario of 32 SCs instances.
• Hardware attestation: A hardware-tampering attack has been simulated by changing the reference value of the hardware and rebooting the platform for the hardware change to take place. When the system boots up, an initial attestation is requested from the node which triggers a change in reference value and the attack is detected. • Firmware attestation: An attack scenario is simulated by disabling the Secure boot configuration in a platform and rebooting the platform for the firmware change to take place. The AE detects the change in the UEFI configuration when the system boots up and performs initial attestation on the node. • OS Verification: An attack scenario is depicted where a new binary file is added to the system by a malicious actor which will create a new IMA measurement. As the node is being attested periodically with an attestation cycle of 10 mins, the attack is detected by the AE immediately in the next attestation cycle. • Runtime Attestation with DIME: An attack scenario is simulated by injecting a kernel module in the platform. Since HPE DIME continuously monitors and verifies portions of OS kernel using a scanning engine, the attack is detected instantly with an average detection time of 10 sec. • SC Attestation: Two attack scenarios have been simulated: (i) a malicious modification to a legitimate executable present in the image of a container belonging to a SC, (ii) the injection of an unauthorised binary inside a container of a SC. Both types of attacks are immediately detected at the next attestation cycle and the overall time taken by the AE to assess the integrity of each SC running on the node has been logged to estimate the average time to detect a compromised SC. The experiment has been repeated as the load on the SCHI node increases, in order to evaluate whether the number of deployed SCs impacts AE performance.
Implementation: The RS implementation is designed with a Finite State Machine (FSM) framework build upon the Spring state machine library. An FSM is a computing model that mimics sequential logic through a set of inputs and the implementation of a finite number of states and transitions that describe and regulate execution flows. RS enacts recovery policies when attestation faults are detected to direct automated mitigations, as well as interfacing with a front-end for action needing human intervention. RS executes its predefined FSM as a recovery policy to respond with necessary actions. One of the RS recovery policies in PALANTIR is the re-instantiation of the failed SC by calling the SO endpoints to stop and to re-instantiate the failed SC. The execution of the RS recovery policy is initiated once the AE sends the information about the failed attestation of the SC. In this recovery policy, RS is also capable to notify the user about the executed actions.
With the implementation of this evaluation, we measured the average time of the RS component applying the recovery policy. The flow was as follows: first, RS received the JSON input where an instance of SC was marked as a failed. This triggered the flow where RS called the REST endpoint of the SO to stop the failed service. Once the service was stopped, a notification was sent from RS over a Kafka topic to inform the Portal about the performed action. After that, the RS called another endpoint from the SO to create a fresh instance of the failed SC. Once this was done, RS sent again the notification message to the Portal over the Kafka topic, which concludes the flow. We measured the total running time (from the beginning to end of the flow) and the average time for one request, as well as the efficiency of the message retrieval.
Testbed: To evaluate the RS we prepared a Python script to measure the RS execution times. We used the ORION testbed, the original environment used in the PALANTIR project. SFERA hosts an on-premises VM that is connected to the testbed over the Kafka cluster from ORION. Table 3 describes the environment of the VM, and frameworks/libraries used in the deployment and testing of the RS.
The VM that hosts the RS system is built with Spring Statemachine, and it has the Eclipse Papyrus tool installed. Eclipse Papyrus can also be installed and used to deploy policies outside the test environment, since it does not affect the RS VM if it is not running. To provide the real-time execution, the RS VM runs new instances on each incoming request based on the detected threats. Once the execution of the RS policy has reached to the final state, the instance is stopped. The FBM contains the Kafka and REST API endpoints to communicate with other systems and components.
Evaluation: For the evaluation we used multiple threads in the form of Multiple-Input and MultipleOutput (MIMO) method. With this evaluation we are testing the platform's capability to scale up and proceed with concurrent remediation action on several nodes simultaneously. Results are presented in Figure 4. We did not experience difficulties while using threads, and messages delivery was successful since RS was able to handle the speed of incoming requests. In case of difficulties, a solution could be to implement multiple RS instances and split the requests. A remediation request basically represents the execution of one remediation policy. The time needed for the RS to finish with one remediation request is 10,13 seconds. For the load test we used 10 threads, which would represent 10 users sending remediation requests at the same time (simultaneously). With those 10 threads we tested with 1, 2, 3, 4 and 5 remediation requests and observed the times. To constitute the dataset, we conducted 4 measurement iterations. Those are the results for this research project; however, when PALANTIR is used in industrial settings, we anticipate being able to handle higher loads by scaling up the component's instances in response to demand. Results show that the total time increases linearly from 50,91 seconds for 10 threads and 1 request to 265,35 seconds for 10 threads and 5 requests. The average time for one request, or the average time for one remediation execution to finish is under 60 seconds for each testing case.
First, and to provide data that contributes to the assessment of the trustworthiness of every new registered node (typically, a running SC instance), the attestation and monitoring modules internal to SO extract and exposes data coming from the SCHI to other components in the architecture. Specifically, data is recovered from (i) the container runtime and (ii) the running SC instances themselves. The internal attestation module provides runtime details, which are passed to the AE during any new SC onboarding and deployment – where the AE uses a subset (i.e. container ID, image ID and IP) to access the nodes and images subject to the integrity attestation. The internal monitoring module registers, persists and exposes generic (e.g. resource consumption) and/or custom metrics (subset of UNIX-like commands) requested on specific running SC instances.
Secondly, the SO interfaces indirectly (via OSM) or directly with the SCs and SCHI, respectively, using encrypted TLS channels with mutual authentication. These interfaces are named after the reference points laid out in the ETSI NFV architecture. The first one is named “Ve-Vnfm-em" and interconnects OSM with the VNF Manager (VNFM), and the VNFM to the Element Manager (EM), which is ultimately in charge of passing the configuration actions that are part of the decision enforcement. The VNFM is implemented by a third-party software (Canonical’s Juju), where the Juju controller interacts with the Juju units (or applications being deployed) over TLS-encrypted websockets. The last one is the Or-Vi interface, where the SO accesses the Kubernetes cluster that is part of the SCHI in the canon, secured way, i.e., through the usage of a kubeconfig file with appropriate credentials (based on X509 certificates).
Testbed: The ORION testbed used in the PALANTIR project was used also here. This evaluation procedure considers the two nodes (VMs) allocated for OSM and SO as part of the control plane, where each of them deploys their specific features across interconnected containers. On the other hand, the Kubernetes cluster consists of one master and three worker nodes (two of them VMs and one a dedicated server with TPM2). Details are provided in Table 4. • 1 Gbps Internet connection
Typically, all Kubernetes nodes, except one (the dedicated server with TPM 2.0 to support the integrity measurement of the virtual containers running on the Docker container runtime) are tainted so to not perform scheduling. However, these tests target the performance evaluation for typical SO operations within the two control plane nodes. Since the attestation procedure does not affect the scheduling in the worker nodes, all nodes were used in the end, disregarding their role.
Evaluation: Given the intermediate position of the SO in the orchestration pipeline, this evaluation aims at identifying the extra time incurred by this component compared to the bare usage of OSM (the MANO leveraged by SO). The three possibilities that can be leveraged during the mitigation and decision enforcement procedures are taken as metrics and measured, i.e. (i) instantiation, (ii) reinstantiation and (iii) configuration times. The first and third metric cover the steps that can be (all together or separately) incurred during each mitigation process, where a new SC instance is instantiated in the adequate network segment to protect and/or where the configuration of a running SC is necessary. The second metric focuses on measuring the time required for the outcome of a failed integrity assessment, where re-instantiation occurs when a compromised, running SC instance is terminated and, instead, a new one of the same type is re-instantiated.
Three Python scripts measure each of the three metrics for the SO, and another three scripts act as counterpart for OSM. Each script iterates the operation defined by the metric N (50) times over each type of SC. This is done sequentially and in batches of R (5-15) requests, reverting that same operation at the end of the measurement of that request and waiting for S (25-60) seconds before moving to the next request. The reverting and waiting process is enforced to minimise the risk of leftovers that can otherwise significantly increase the measured times, due to constraints on disk space and hitting timeouts. Time is measured right between submitting the action(s) and receiving the success confirmation that corresponds to each request. The resulting times per metric, comparing the two instantiation “types” (SO vs OSM) are depicted in Figures 5, 6 and 7. It is worth noting that each request to any of these components is (i) enacted sequentially (not concurrently with any other pending operation); (ii) independent from any other (disregarding order and relations); and (iii) idempotent (leaving the environment in the last clean state after every request). These tenets have facilitated measuring in the optimal conditions for the chosen testbed.
This subsection reports the results obtained in the evaluation of the overall reaction time of the PALANTIR framework to force a remediation action as soon as a compromise to a SC is detected. To estimate this time, a Bash script was created to simulate an attacker which compromises a SC by maliciously modifying one of the image's binaries and then executing it. Time was acquired from the moment the attack is executed to the moment the compromised SC is terminated by the SO. Figure 8 shows the results of 30 measurements performed using snort_ns as SC and the average value obtained, equal to about 73 seconds, while Figure 9 shows how the time is distributed among the various components. During the experiments, the AE was configured to perform an attestation cycle every 2 seconds and to send notifications to the RS every 10 seconds; and the RS was subjected to a workload of 1 remediation request at a time. From the data it emerges that the ZTA architecture of the PALANTIR framework guarantees that, in less than 2 minutes, an attack aimed at compromising the integrity of the SC is detected by AE, processed by RS by sending a request to remove the SC untrusted and resolved by SO forcing its removal from SCHI.
ZT security model suggests that no request for access to a resource of the infrastructure must be considered trusted a-priori and that the integrity of each infrastructure component must be constantly monitored and evaluated. While architecting PALANTIR, the authors thrive to comply to this paradigm, which replaced the traditional one based on the network perimeter, no longer applicable to modern virtualised distributed infrastructures. NIST defined a ZT security model through a set of seven basic tenets, conceived as ideal objectives that should be realised in a ZTA, fully or even partially depending on the strategy adopted in each context. We examined the PALANTIR architecture considering such tenets to evaluate which of them are met into the infrastructure and to what extent. Table 1 exposes how PALANTIR platform complies with these principles when managing security capabilities according to their security posture.
This paper proposed, prototyped, and evaluated the PALANTIR ZT architecture, justified it with an MSSP threat model, and analysed its compliance with the ZTA paradigm, highlighting how the basic ZTA tenets are satisfied in the PALANTIR framework. An extensive range of experiments was conducted in order to demonstrate the effectiveness of PALANTIR's ZTA solution and the feasibility of its adoption in real operational scenarios for the protection of SMEs and ME. Even though PALANTIR shows remarkable progress in terms of applying ZTA principles to the SecaaS model, further improvements can be investigated and applied. As future work, the ZTA security model should be considered on different perspectives, not only tied to the PALANTIR infrastructure itself, and extended by adopting some of the presented solutions directly on the customer infrastructure (e.g. remote attestation).
The work described in this article has received funding by the European Union Horizon 2020 research and innovation programme, supported under Grant Agreement no. 883335. Part of this work is also supported by the Spanish Government Grant ONOFRE-3 PID2020-112675RB-C43 funded by MCIN/ AEI /10.13039/501100011033. The content of this article does not reflect the official opinion of the European Union or any other institution. Responsibility for the information and views expressed therein lies entirely with the authors.