# PALANTIR: An NFV-Based Security-as-a-Service Approach for Automating Threat Mitigation
## 5 Data Modelling
### Constraint Satisfaction Problem for Enabler Selection
#### 5.3.1 Infrastructure-Issued Constraints  
We first tackle the constraints related to the consumption of computing resources on infrastructure. We assume an infrastructure \(I_{q}\) belongs to a set of infrastructures (denoted by \(\mathcal{I}\)) and is modeled as a tuple of its computing characteristics and a set of Boolean values reflecting the supported deployment model. Currently, our infrastructure model accounts for (i) the number of CPU cores available, (ii) the amount of RAM available, and (iii) the persistent storage space available. We also reflect on the different deployment models for specific mechanisms. In real-life scenarios, we aim to discriminate the infrastructures from cloud computing, edge computing, and on-premises location, as their different technical natures will encourage the developers of the mechanisms to produce different versions of their component, adapted to each specific type of infrastructure. Reasoning in terms of resource limitation permits us to implement an approach featuring the backpack problem, known to be NP-hard and representing a suiting case for constraints programming usage. One naive method to model infrastructure resource constraints consists in ensuring each component's resource requirement does not exceed what infrastructure can provide. Therefore, we may think that for blocking the allocation of a mechanism to an unsupported infrastructure type, we should change its resource consumption to be unlimited, to ensure the constraint is systematically violated when the solver will consider such deployment. However, some infrastructures (such as public clouds) may be modeled with an unlimited number of resources as well, driving the solver to an unpredictable state when evaluating the constraints. We overcome this pitfall by adopting a two-fold approach: we first model infrastructure and components reflecting their resources on offer and demands, and then their compliance and compatibility with the deployment models. We can now write  
\[I_{q}=<r_{q}^{cpu},r_{q}^{ram},r_{q}^{qg}>\in\mathbb{N}^{3} \tag{3}\]  
where \(r_{q}^{cpu}\) stands for the number of CPUs provided by the infrastructure \(q\), \(r_{q}^{ram}\) for its level of RAM, and \(r_{q}^{qg}\) for its storage capacity. Similarly, for all \((m_{i})_{0\leq i<n}\), we adopt the following notation:  
1. \(r_{m_{i},q}^{cpu}\) indicates the amount of CPU needed on infrastructure if deployment configuration \(m_{i}\) is enacted;
2. \(r_{m_{i},q}^{ram}\) states the amount of RAM needed;
3. \(r_{m_{i},q}^{alg}\) stands for the required storage capacity. These values can be null if the deployment configuration \(m_{i}\) does not operate infrastructure \(q\). Therefore, if \(m_{i}\) is mono-infrastructure, there is only one infrastructure \(I_{q}\), for which \(r^{cpu}_{m_{i},q}\), \(r^{ram}_{m_{i},q}\), and \(r^{sq}_{m_{i},q}\) are non-null. Therefore, we can formalise the first set of constraints to assess which mechanisms \(I_{q}\) can support for deployments. The first equations relate to resource consumption:  
\[ \begin{split}&\sum_{0\leq i<n}x_{i}r^{cpu}_{m_{i},q}<r^{cpu}_{q} \\ &\sum_{0\leq i<n}x_{i}r^{ram}_{m_{i},q}<r^{ram}_{q}\\ &\sum_{0\leq i<n}x_{i}r^{sq}_{m_{i},q}<r^{sq}_{q}\end{split}  \tag{4}\]  
They can be read as the sum of resource requirements for one deployed mechanism that have to be less than what the infrastructure can provide. We can generalise (Equation (4)) to all security mechanisms by considering not just the sole set of deployment configurations of a single mechanism, but all of them:  
\[ \begin{split}&\sum_{0\leq i<n^{\prime}}x_{i}r^{cpu}_{m_{i},q}<r^{ cpu}_{q}\\ &\sum_{0\leq i<n^{\prime}}x_{i}r^{ram}_{m_{i},q}<r^{ram}_{q}\\ &\sum_{0\leq i<n^{\prime}}x_{i}r^{sq}_{m_{i},q}<r^{sq}_{q}\end{split}  \tag{5}\]  
This gives us the first set of constraints for a given infrastructure. They have to be evaluated for every single infrastructure \(I_{q}\) considered for deployment.