Secure Context Execution Enforcement based on Activity Detection:

This section discusses and analyses the secure context execution control framework presented in chapter 4.

7.1.1.1 Explanatory example

Suppose an application PU1 is attempting to access a data file DF1 and consider the following policies:

1. POLDF1: (label=email-apps, write, DF1, {Wi-Fi=on}, allow) 2. POLPU1: (PU1, write, label=contact-list, {location=home}, allow) 3. Host System permissions:

a. RESPERMISSION (DF1, {contact-list}) b. RESPERMISSION (PU1, {email-apps, trusted})

4. POLHS1: (PU1, use, Network-Interfaces, {anti-malware=enabled}, allow)

To determine whether to grant PU1 access to DF1 the Policy Manager Module (PMM) (see Figure 22, Chapter 4) executes the following steps:

145

Step 1. The PMM retrieves the policies associated to DF1 (1) and PU1 (2) and checks whether it needs to resolve any labels (or categories). In this example, both policies (1) and (2) define labels, that is, email-apps and contact-list, respectively.

Step 2. The PMM retrieves the Host System Permission assignments for DF1 (3a) and PU1 (3b) and tries to resolve for permitted labels in order to parameterise policies (1) and (2). In this case, (1) and (2) become:

5. POLDF1’: (PU1, write, DF1, {Wi-Fi=on}, allow) 6. POLPU1’: (PU1, write, DF1, {location=home}, allow)

Policy combination:

Step 3. Once all the policies are specified, the PMM retrieves any Host System applicable policies associated to both DF1 and PU1 – in this case policy (4) applies to PU1; and applies the corresponding evaluation rules (see 4.5.5 Table 1) over policies (4), (5) and (6),

eval {(PU1, write, DF1, {Wi-Fi=on}, allow) AND (PU1, write, DF1, {location=home}, allow)

AND (PU1, use, Network-Interfaces, allow)}

Step 4. If the result of eval({}) is false the PMM denies PU1 access to DF1. If the result is true the PMM allows the execution and specifies the following combined policy:

7. (PU1, access, DF1, {Wi-Fi=on, location=home, anti-malware=enabled}, allow)

Step 5. The combined policy defines an active execution context that evaluates to ALLOW given the conditions defined in it, and that must be enforced by the Policy Enforcement Module (PEM) and monitored by the Secure Context Monitor (SCM) as per Figure 22.

From this example different aspects of the mechanism are discussed in the following subsections.

7.1.1.2 Abstract and executable policies

The policy model distinguishes four types of policies: the individual policies defined on hosted processing units and data files by their administrative entities, i.e. (1) and (2); baseline host system policies, i.e. (3a), (3b), and (4); parameterised policies (5) and (6); and the resulting combined policy (7).

Identifying abstract policies from executable policies depends on how the terms abstract and executable are understood and defined. In the case of the protection mechanism here

146

discussed, the combined policy (7) is considered as the executable policy because this is the actual policy enforced by the Policy Enforcement Module (PEM); whereas policies (1), (2), (3a), (3b), and (4) are abstract policies as shown in Figure 53. The translation from abstract policies into executable policies is achieved by means of the policy integration (Steps 1 and 2) and policy combination (Steps 3 and 4) mechanisms. Policies (5) and (6) are in between and can be considered as abstract policies but less abstract than (1) and (2).

Figure 53 Abstract and executable policies

In fact, defining abstract and executable is a matter of perspective and strongly depends on how the system is understood. Here, the combined policy (7) is the executable policy as it is the lowest level of abstraction considered in the design of this specific protection mechanism. However, an even lower level of abstraction would consider, for example, the low-level policies enforced at kernel level by the policy enforcement points (PEPs) of the system as the executable policies. In any case, depending on the system to be modelled or designed and the security requirements this must be taken into consideration as policies at different levels provide different levels of control, expressiveness, and granularity.

The running example describes how this system translates from abstract policies into an executable policy taking into account and combining the security requirements of multiple entities. Another aspect to consider is related to how the system delimits the behaviour introduced by processing units and data files’ policies.

The host system administrator defines baseline host system policies (4), and permissions (3a, 3b) specifying labels that characterise and categorise protected resources in order to determine under what conditions users, processing units, and data files can be accessed or used. In other words, baseline host system policies affect the behaviour of the overall system and, in essence, are used as a scoping mechanism to control the allowed behaviour for users, PUs and DFs.

Abstract

Executable

POLDF and POLPU, Host System Base Policies

Parameterised Policies

Combined Policy Integration

147

For example, consider again the same policies of the explanatory example, but suppose that at this time only policy (2) is modified and becomes:

8. POLPU1: (PU1, write, label=contact-list, {location=work}, allow)

Notice that the only difference is in that location changed from “home” to “work”. This would produce the following combined policy:

9. (PU1, access, DF1, {Wi-Fi=on, location=work, anti-malware=enabled}, allow)

This is to show that although the policy of PU1 (2) is modified to (8), a new combined policy (9) is generated that is compliant with the baseline policies of the host system, i.e. it is within the allowed scope. In other words, the executable policy changed, thus changing the way the system behaves, while the baseline policies remained unchanged.

7.1.1.3 Protection mechanism and adaptation

Security decisions are made by the proposed architecture, or, more precisely, by the policy combination component (PCC) in the policy management module (see Figure 22) and depend on three elements that change dynamically: host system baseline policies and associated permissions; individual policies defined on hosted processing units and data files; and system state and contextual factors. These three elements may change for different reasons. Any policy issuing entity can add, remove, or modify policies; and also the execution context may change due to activities or events triggered by the entities interacting. As a result, these three elements introduce adaptation to the protection mechanism via the PCC (shown in more detail in Figure 54) that: reacts by generating a new security decision, i.e. the combined policy; requests the PEM to enforce a dynamically generated secure execution context; and requests the Secure Context Monitor (SCM) to monitor that the conditions defined in the combined policy hold true over time.

Figure 54 Policy Combination Component and the adaptive decision-making process

Adaptive decision-making process

Policy Integration Process

Policy Combination Process

Policy Evaluation Process Secure Context

Monitor

Policy Enforcement

148

It is important to emphasise that the PCC does not have a predetermined way of dealing with detected activities or events. It all depends on the policy integration and combination process, and the interacting parties and protected resources, and their associated policies.

As shown in Figure 54, the PCC can be decomposed into three subcomponents: policy integration process component, policy combination process component, and the policy evaluation process component. Recall from the explanatory example that the policy integration process corresponds to steps 1 and 2, and that the policy combination process corresponds to steps 3 and 4. The final step is the evaluation process, step 5. The decomposition into subcomponents is important to understand how adaptation is introduced into the system.

More specifically, adaptation is introduced at two levels. First, the policy integration and policy combination processes (see Figure 54) have as output a combined policy that is passed to the policy evaluation process to drive the security decisions of the system. This property makes the system adaptive since the combined policy is a runtime dynamically created new policy that did not exist in the system before the involved entities chose to interact. This is equivalent to a policy reconfiguration in the system which creates a totally different behaviour propagating it to the policy enforcement mechanisms. The second level of adaptation is the scoping effect caused by the new policy introduced into the system which is context-based.

Here, the policy combination component (PCC) could be viewed as an adaptive engine consisting of a context-based policy decision point (PDP) extended with two adaptive layers, i.e. policy integration and policy combination. This would be a desirable architectural choice as a way to introduce adaptation into an existing mechanism with a PDP or Policy Engine, such as XACML [76], as one of its components.

7.1.1.4 Specialisation of the protection mechanism

The proposed protection mechanism can be specialised to specific host devices. There are different types of smart devices such as laptops, tablets, smart TVs, game consoles, smartphones, and so on. Each type of device determines a unique execution environment with its own characteristics and properties. For example, a smart device can be characterised by the type of operating system it runs, and the available system resources such as network interfaces, communication protocols, sensor components, kernel, and available APIs. Also, it can be characterised by its form factor, by how it interacts with its user(s) via interfaces, and by important properties such as portability, multi-purpose, multi-function, and multi-user.

149

Based on these characteristics and properties the secure context execution control framework introduces into the environment appropriate security constraints, in this specific case policy enforcement points, in order to control the execution context and provide isolation for data files and processing units. For instance, a policy enforcement point to block how the user can interact via a display screen is suitable for a smartphone; however, in the case of a game console it would be more appropriate to have an enforcement point at the communication interface between the console and a display connected externally.

More importantly, at the logical level, specialisation is achieved via the policy integration process (see steps 2 and 3 in the running example) since it is during this process that the host system baseline policies resolve labels and permissions and parameterise policies. And in essence, the effect of this process is to logically integrate and delimit what states of execution are allowed or not.

7.1.1.5 Security model: Enhancing adaptation with overrides

Recall from section 4.5.2 that in order to provide flexibility, during policy combination, policy rules were extended with the concept of overrides. The concept of overrides allows processing units to transfer decision authority to other processing units when a certain context-based policy is met. This feature is a form of trust delegation from one policy issuer entity to another. The overrides mechanism extends policy transformation by providing a security model to dynamically support security decisions.

As explained before, the policy combination component takes as input the policies from different administrative entities and produces a combined policy which represents an active secure execution context for the specific execution environment of the host device, and the end result is an overall system whose runtime behaviour is adaptive and dynamic. In essence, the behaviour of the system is based on understanding and incorporating the individual security requirements of all the entities interacting and whose policies reflect their intended actions.

7.1.2 Privacy and Security Requirements Enforcement Framework for