# PALANTIR: An NFV-Based Security-as-a-Service Approach for Automating Threat Mitigation
## 4 PALANTIR General Architecture for Threat Remediation
### Overview of the Architecture  
Figure 1 outlines the PALANTIR general architecture. SCs are the protection mechanisms (security enablers) of PALANTIR, being managed and deployed by the SO into the SCHI to realise their function.  
On the other hand, the SCHI is composed of the VIM and the NFVI. The SCs are interfaced by the SO via the interface _VeNf-Vnfnfn_, the component in charge of the SCs (i.e., the SecaaS solutions) life cycle management. The SO incorporates some key elements such as Monitoring and Package, explained in detail below in Section 4.4. The SO is connected to the SCHI to correctly instantiate SCs and the SC Catalogue (SCC), understood as the SC repository with the descriptors and metadata to deploy whichever SC is registered in PALANTIR. The SO and the SCC maintain a tight bond to shape the SC Orchestration (SCO).  
Accordingly, the PALANTIR platform has the Trust, Attestation, and Recommendation (TAR) component, where the Recovery Service (RS) and the Incident Response (IR) are hosted. These two components monitor the SCHI and SCs and report alerts/messages with remediation procedures to mitigate threats. Finally, The PALANTIR Portal is the connection with the final user, that is, the information point used by the client in order to know the current status, in real time, of the infrastructure. The Portal is also in charge of the Accounting section, and includes Service Matching (SM) as the component with the proper knowledge of selecting given SCs under certain conditions and the results obtained. The PALANTIR Portal is connected to the SO via the _Os-Ma_ interface to receive notifications about the SCs life cycle and other events occurring in the SCHI.  
When compared to the 5G's Service-Based Architecture (SBA) [48], the PALANTIR architecture also (i) separates the user plane (client's infrastructure) from the control plane (central layer), where the latter hosts common core functionality, as presented in Figure 2; (ii) provides a central repository (the SCC) that allows the system to expose new network functions in the same fashion as the Network Repository Function (NRF) in SBA; (iii) enables SC instances (as NFs) to be exposed and consumed in a loose manner and without impact on other existing SCs of NFs; and (iv) enables inter-NF communication (or from other applications), as the functionalities implemented by the SC instances are exposed via the SO and accessed through TLS channels (e.g., to request data from another SC instance  
Figure 1: PALANTIR general architecture.  
or configure it, as required by the encompassing network service). All of this partially enables the logic devised for the Network Exposure Function (NEF) in SBA. On the other hand, and different to SBA, (i) the SC instances (as NFs) are not considered as part of the control plane, but are instead deployed and operate in the user plane, covering the client's infrastructure; (ii) the core functionality is not restricted to acting in the network, and thus is not designed as NFs, but nevertheless follows a Service-Oriented Architecture (SOA), suited for heavy integration.