Parallel composition: policy union, intersection and difference

The second type of policy compositions supported by SANTA is the parallel composition.

With this type, multiple policies can be enforced simultaneously, in parallel to each other. In its simplest form, policies can be combined by merging their rules, as shown in Table 4.6.

Example 19: Merging simple policies (union). This set of examples demonstrates how policies can be composed in a parallel manner. The policy p_open is an an open policy, which only defines denials and allows anybody (S) to perform the action a on the object o, by default. Similarly, the policy p_closed is a closed policy, which only states permissions and allows the action a on the object o explicitly. Finally, it is possible to merge the two policies to produce a parallel composition. The lengthy notation can also be shortened, as it contains redundant statements.

policy p_open::

decide(S, O, A) when 0 : not deny(S, O, A) end

policy p_closed ::

allow(S, o, a) when true

decide(S, O, A) when 0 : allow(S, O, A) end

policy p_composed::

allow(S, o, a) when true

decide(S, O, A) when 0 : allow(S, O, A) decide(S, O, A) when 0 : not deny(S, O, A) end

policy p_composed::

allow(S, o, a) when true

decide(S, O, A) when 0 : allow(S, O, A) or not deny(S, O, A) end

Example 20: Rule syntax vs semantics. As it follows from the examples above, the intersection of the two simple policies is empty according to their syntax. Nevertheless, the semantic of the two policies are essentially the same – that is, the intersection of the policies is expected to be p₁, which is equivalent to p₂. Therefore, there is a requirement to introduce an operator for policy compositions, which would also capture the semantics of the policies. A potential way of achieving this functionality is to evaluate individual policies constituting the policy composition independently from each other – that is, as a self-contained entity. As a result, the policy composition (i.e., union, intersection, or difference) is defined using a decision rule, which considers outcomes of the both policies (please refer to Example 21).

policy p₁:: allow(S, O, A)when true end

policy p₂:: allow(S, O, A)when 0 : true end

Example 21: Policy composition (intersection). This example represents an intersection of two policies p₁and p₂. To express this kind of composition, we use the ternary operator par. The policy p₃ in this example is defined by the outcomes of policies p₁and p₂. It defines the intersection of the two policies as an authorisation decision, which is made only if both policies p₁and p₂agree on the outcome. The advantage of this approach is that the meaning of the component policies as a hybrid combination of a positive, a negative and a decision rule is preserved. The par operator is able to capture the semantics of the compositional policy, which can then be referred to in the de-confliction policy that defines whether decisions have to be made by the policy composition. The composition preserves the semantics of the component policies. To remove the need to explicitly specify a de-confliction, it is possible to omit the deconflict part of the par construct. In this case, the example can be shortened to the one presented in Example 22.

policy p₁:: allow(S, O, A)when true end

policy p₂:: allow(S, O, A)when 0 : true end

policy p₃:: p₁parp₂deconflict { decide(S, O, A) when p₁.decide(S, O, A) and p₂.decide(S, O, A) }

Example 22: Policy composition. This example illustrates a situation when the policy p₁ will become effective after 10 time units, if the policy p₂also becomes effective. In this example, the policy p₃is defined by the outcomes of the policies p₁and p₂. The policy p₃ defines the intersection of the two policies – an authorisation decision is only made if and only if both policies p₁and p₂agree on the outcome.

policy p₁:: allow(S, O, A)when true end policy p₂:: allow(S, O, A)when 0 : true end policy p₃:: end

p₂par (10 : p₃; p₁)

Table 4.6 SANTA policy union, intersection and difference.

Existing limitation: insufficient support for data privacy In the previous section, we demonstrated the capabilities of the SANTA language to handle various security- and access control-related use case scenarios. As we have seen, using SANTA it is possible to define and enforce policies governing access to bank accounts, electronic submission systems, procurement systems, etc.

Moreover, as we have seen, the application scope of SANTA is not limited by specific platforms – it can apply to relatively small-scale systems and large enterprise concurrent systems with multiple users trying to access resources. Therefore, it is also expected to be applied in the cloud context ‘out of the box’. As demonstrated by the use case examples, all of them can be executed in a wide range of distributed systems, including cloud environments.

Cloud environments are complex virtualised environments, which are characterised with large amounts of data being dynamically transferred in and out. Every single moment, cloud users upload and download gigabytes of their personal data, and cloud-hosted software handles terabytes of potentially sensitive business data. In these circumstances, it is essential to ensure that these amounts of data remain secure and private. Data privacy and protection have been seen among the key challenges for the comprehensive adoption of cloud services.

Admittedly, various techniques, such as data encryption, data replication and recovery, have proven to be useful when data was lost or stolen by an unauthorised/malicious user.

However, what if would not escape from the owner’s control in the first place? In other

words, it might make more sense to implement an efficient access control mechanism, which would enable data privacy throughout the whole lifecycle of users’ data sets within cloud environments. The life cycle of cloud-hosted data typically includes the following phases:

• Data is uploaded by the user over the network

• Data is stored on a cloud server

• Data is moved from one cloud server to another transparently to the user

• Data is downloaded by the user

Arguably, all of these phases are associated with a potential threat of an unauthorised access to data. Accordingly, as far as cloud environments are concerned, it is essential to ensure that data remains private at all times – one of the fundamental requirements for creating a trusted cloud service and attracting customers.

However, as we have demonstrated with the list of use case examples, the SANTA language at its current stage is incapable of addressing the pressing challenge of enabling data privacy across multiple network locations, such as the cloud and the private network.

ITL is considerably good at handling the history of data access over a period of time, but currently is not expressive enough to capture the location dimension, but location-aware data privacy is currently beyond existing capabilities of the SANTA language due to the lack of corresponding expressivity power and underpinning logical formalism.

In this light, it becomes important to employ an approach to effectively and efficiently differentiate between various network locations, and – at the same time – combine it with the existing access control policies. Such an approach, as described in the next sections, is based on the logical notion of location that lies at the core of topological logic.

4.7 Formalising the notion of location and location