# Secure Partitioning of Cloud Applications, with Cost Look-Ahead
## 8 Concluding Remarks and Future Work  
This article introduced a declarative methodology to determine safe partitionings of Cloud applications in order to support their secure deployment onto separation kernel technologies, i.e., trusted execution environments. The methodology is implemented in two Prolog prototypes  
* SKnife, which determines the minimal eligible partitioning, the partitioning with the minimum number of domains that satisfies the initial labelling, and
* ProbSKnife, which determines all the eligible partitionings up to a user-defined limit of domains and calculates their future migration cost based on the probability of changing the application labelling. We introduced the threat model of our considered scenario, which considers unreliable infrastructure providers and external attacks able to compromise the data confidentiality of an arbitrary multi-component application running on Cloud-IoT nodes. Then, we showed how we employ information-flow security to determine eligible partitionings of the application in order to support the deployment onto separation kernel technologies to tackle such threats. We showed how SKnife finds the minimal eligible partitioning and, after introducing our probabilistic cost model, we showed how ProbSKnife determines the eligible partitionings and their future cost parametrised by K--the maximum number of label changes--and DLimit-- the maximum number of admitted domains. Finally, we discussed the execution time and the future cost of ProbSKnife varying K and DLimit through experimental assessment. The results of our experiments show that the execution time of ProbSKnife is exponential in the number of label changes and that bounding K to low values is crucial to have a solution in a reasonable time, reducing it from 8 hours with K = \(\infty\) to milliseconds with K = \(1,2\). Moreover, the results emphasise how it is necessary to have a way to fine-tune the maximum number of admitted DLimits. Too-low values of DLimit reduce the SK impact and the execution time of our prototype. On the other hand, low values of DLimit reduce the number of possible starting deployments and increase the probability of changing the deployment in the future. To conclude, we highlight three possible directions for future work to enhance our methodology. **Software engineering-based suggestions**: Currently, we deal with non-safely partitionable applications by suggesting relaxed (data or characteristic) labellings. An interesting alternative is to use software engineering techniques to determine modifications of the application architecture in order to avoid data leaks without changing the overall application behaviour. By introducing standard components or architecture patterns, the isolation of untrusted components could be improved and the data could be decllassified before sending it to the untrusted components. **Future cost determination**: ProbSKnife computes the exact value of the future cost for all initial safe partitionings. This can be very time-consuming for applications with several components or dealing with a high number of data types and characteristics. An interesting line for future work is to determine an ordering of the partitioning's future costs, without actually computing their values exactly. We are devising an iterative method that determines boundaries on the probability of migration of partitionings, thus reducing the boundaries at each iterative step in order to contain the execution times. **Mathematical optimisation**: As a last line for future work, we are investigating how to formalise our considered problem as a mixed-integer linear programming problem. This would enable comparing our approach with established optimisation schemes, both from qualitative (viz., application modelling, readability) and quantitative (viz., execution times, solution costs) viewpoints. **Author Contributions:** Conceptualization, A.B. ([PERSON]), S.F., R.G., G.-L.F. and A.B. ([PERSON]); methodology, A.B. ([PERSON]), S.F., R.G., G.-L.F. and A.B. ([PERSON]); software, A.B.