# PALANTIR: An NFV-Based Security-as-a-Service Approach for Automating Threat Mitigation
## 5 Data Modelling
### Ontology  
Complete data modelling allows PALANTIR to act consistently and exhaustively against different threats and anomalies. In this context, the ontology defines the information used by the involved elements in different processes and tasks. Thus, the ontology is required to perform correct remediation procedures. The final intent of this ontology is to best understand which security mechanism to leverage under certain conditions, looking for the CAPEX and OPEX financial sustainability from a client's perspective.  
Figure 4 depicts the ontology with its different classes and relations. It contains seven classes, which relate to the main PALANTIR components involved in the remediation procedures. Their significance and relationships are described below.  
* The _Data Type_ represents the different data modalities contemplated in PALANTIR (e.g., NetFlow and Zeek data). This class is connected to the _Protection Method_, and uses the latter as input.
* The _Protection Method_ class defines the detection and mitigation methods (i.e., the two types of available protection) as its subclasses. It is connected to two specific classes: _Security Capability_ and _Threat_.  
Figure 4: Ontology defined for the formalisation of data in the PALANTIR remediation procedure.  
* The _Security Capability_ class is the formal name for the security mechanisms, and it refers to the virtual element developed to be deployed in the client infrastructure. This class supposes a central part of the ontology because it has a relationship with a large portion of the ontology classes. Section 5.5 delves into details about the properties and metadata modelling this class. In addition, a _Security Capability_ can implement one or more protection methods and is related to the _Threat_ class, contributing to mitigate the effects represented by the latter.
* The _Threat_ class defines the threats/attacks following the indications of threat modelling methodologies such as OCTAVE [53] and STRIDE [54], well-known tools for representing such types of activities. This class is also connected to the _Billing Model_ and _Incident Response_ classes because it directly affects the data allocated among both classes.
* One the one hand, the _Billing Model_ class represents the different fees to be applied regarding the deployed SCs and the contracted characteristics. The connection between the _Billing Model_ and _Threat_ classes is due to a _Threat_ generating a remediation procedure that deploys a new security mechanism. This fact is also represented by the connection between the _Billing Model_, _Incident Response_, and _Security Capability_ classes.
* In addition, the _Billing Model_ depends on the _Deployment Model_; the latter defines the deployment models available, which have associated different physical resources, operation modes, etc.
* Finally, the _Incident Response_ class models the element selecting and performing the remediation procedures when a threat/attack is detected. Therefore, it connects with the _Threat_ and _Billing Model_ classes, already described, but also with the _Security Capability_ class, since the remediation procedure to be performed can result in the reconfiguration of a security mechanism deployed in the client infrastructure.  
The ontology presented in Figure 4 outlines the definitions of the different PALANTIR operations involved in the remediation procedures. This is the case of the SM, where the following flow can be defined: a flow _Threat_ triggering the _Incident Response_, modifying the _Billing Model_ (depended of _Deployment Model_), and configuring _Security Capability_, which mitigates the _Threat_.