# Secure Partitioning of Cloud Applications, with Cost Look-Ahead
## 3 Preliminaries
### Motivating Example
To determine the level of trust of the software components, we assign security labels to the relevant characteristics of the application. We also assign security labels to the application data in order to establish a direct relationship between the data and the trust of the software components. We adopt a total ordering security lattice (viz., top \(\succ\) medium \(\succ\) low) modelling the labels pertaining to both sensitive data and trusted characteristics. The top label denotes both secret data and high-trust characteristics, the medium label denotes both medium-secret data and medium-trust characteristics and the low label denotes public data and non-reliable characteristics. A component having characteristics considered unreliable by the application developer is not able to manage secret data. This could cause a leak of its data toward the directly connected components or toward the software components hosted in the same isolation environment, i.e., container, virtual machine or SK domain. For instance, if the DBMS used by DB is not reliable--either because it is malicious or because it has vulnerabilities--the data of DB can leak toward the Disk, component owned by the Cloud Provider. Furthermore, if DB is isolated in the same SK domain of API Gateway (assuming an unreliable Net Library), the leak of data could flow from the DB to the Network Interface through the API Gateway. We emphasise again that we aim at protecting the data confidentiality of applications placed on the Cloud by finding _safe partitionings_, i.e., grouping the software components in non-empty subsets that allow placement of the application in SK domains in such a way that the data and trust of the components are homogeneous in every domain, avoiding having less-trusted components share the environment with components that manage sensitive data. For instance, we already discussed that AI Framework is a library of AI Learning considered not reliable; it may contain malicious code or its vulnerabilities may be exploited by an external attacker. Placing all the software components in the same domain exposes the data of the application to be read by AI Framework and sent outside such domain. Partitioning the application components to isolate their data and exploiting the SKs' isolation mitigates those kinds of threats. To support the application operator's decision, we aim at determining the _expected migration costs_ of the software components. Migrating the software components could be needed after the deployment of the partitioned applications due to events such as bug discovery or data declassification that bring a change in the labelling of the application. With the new labelling, the partitioning might not be safe anymore. For instance, a bug discovered in the TLS Library declassifies its trust from top to medium and the Authenticator must be migrated to a different domain to preserve the data confidentiality of the application. For these reasons, every software component is also annotated with its migration cost, represented as an integer number. The migration cost represents how many hours of work are needed to change the communication link of each software component during a migration that changes the status of the link from intra-domain to extra-domain and vice versa. For instance, the User Configuration needs 10 person hours to change its communication links. To evaluate the expected costs of migration, we need to know how data and characteristics can change the label over time. Application operators may determine the probability distribution of the change over time by their experience or by exploiting statistical analyses from the open-source community [53]. Table 2 shows a probability distribution to change the label for each data and characteristic of the application. For instance, we can assume that in the future there is a 20% probability of discovering a side channel not easy to exploit in the TLS Library, reducing its trust from top to medium.