# PALANTIR: An NFV-Based Security-as-a-Service Approach for Automating Threat Mitigation
## 5 Data Modelling
### Security Capability Entry Model  
Aligned with the above content, PALANTIR defines a data model for SC entries in the catalogue.  
Essentially, the SCs are represented with two descriptors: the xNF descriptor and NS descriptor. The declaration of these descriptors, defined in NFV-SOL006 standard [57], includes several fields necessary for PALANTIR to identify SCs, namely, the _id_, _provider_, _version_, _product-name_, and _product-info-description_ fields. These fields are exposed by the SO to the rest of PALANTIR platform.  
Furthermore, PALANTIR extends the NFV-SOL006 standard to model the SC entries in the catalogue with the following aspects:  
1. _Qualification of relevant SC:_ PALANTIR defines some fields to classify the type of SC to make clear decisions as to where a new SC must be deployed, derived from the ontology presented in Section 5.1. These are _detection-method_, _mitigation-method_, _control-data-type_, and _monitor-data-type_.
2. _Billing of SC usage:_ To define the requirements presented in Section 5.4, PALANTIR proposes _billing_model_, _subscription_billing_, _instance_billing_, and _hourly_billing_ fields. Each SC has associated a different cost and a billing model regarding its capacities and characteristics.
3. _Assessment of the service-level agreement:_ In this case, PALANTIR categorises the SCs with their service-level agreement applied and the violation fee associated. For this, _sla_ and _sla_violation_fe_ fields are added.
4. _Support for multiple deployment models:_ The SC entry includes some fields to indicate the supported deployment model(s), and the resources needed to the correct SC operation. Therefore, the fields _deployment_model_, _nbCpu_, _amountRam_, and _amountSig_ are defined.  
Finally, PALANTIR takes the importance of GDPR compliance and proposes some fields to be in accordance with such law: (i) _interfaces_descr_ to explain the nature of input/output traffic and the type of data used by the SC; (ii) _gdpr_applicability_descr_ to describe the personal data manipulated, if applies; (iii) _storage_descr_, _processing_descr_ and _sharing_descr_ to inform about the storing, processing, and sharing of client data; (iv) _subject_right_descr_ to allow stakeholders to indicate the rights associated (right to access, right to be forgotten, etc.) with the data used; (v) _open_internet_descr_ to indicate whether SC impacts the respect on Open Internet norm; (vi) _non_discrimination_descr_ to explain how data are used to discriminate users; and (vii) _eprivacy_descr_ to detail the compliance with ePrivacy framework. We detail, in Table 1, the different fields composing the SC entry model.  
\begin{table}
\begin{tabular}{c c l l} \hline \hline
**Name** & **Purpose** & **Description** & **Example** \\ \hline _id_ & SO & ID to reference the SC & ids \\ \hline _provider_ & SO & Designer of the SC & Company \\ \hline _version_ & SO & Version of the SC & 1.0 \\ \hline _product-name_ & SO & Name of the SC & IDS SC \\ \hline _product-info-description_ & SO & Description of the SC & IDS for detection \\ \hline _detection_method_ & Extension & Detection method of the SC & network monitoring \\ \hline _mitigation_method_ & Extension & Mitigation method of the SC & network traffic filtering \\ \hline _control_data_type_ & Extension & Type of data generated by SC & NetFlow configuration \\ \hline _monitor_data_type_ & Extension & Type of data generated by SC & pcap \\ _billing_model_ & Extension & Reference the billing models & hourly \\ \hline \hline \end{tabular}
\end{table}
Table 1: Security Capability entry model fields.