COMENTARIOS Y ANÁLISIS DE LA ADMINISTRACIÓN SOBRE LOS RESULTADOS DE LA

In this section a stepwise approach to describing the blueprint of the methodology from a security perspective is presented.

1. Define the high-level security requirements or security capabilities of the protection mechanism and identify protected assets, possible threats, vulnerabilities, and attacks. This is important in order to reason as to what and where security controls and security functions should be placed within the IT infrastructure and how these controls and functions map to the security requirements of the system.

2. Identify relevant constraints to be introduced into the system. Types of constraints include: (a) those that are determined by the physical or behavioural constraints of the operational/execution environment itself such as e.g. the screen size of a device or the possible control-flows and data-flows defined in a business process description. This type of constraints requires understanding the operational/execution environment and modelling entities and interactions among them; (b) information about the different states of the operational/execution environment. States may be defined at different levels such as transaction or system level; (c) constraints related to QoS aspects such as security, performance, and usability; and (d) contextual parameters, among others.

180

3. Identify relationships among constraints and security concerns. This is a very important step in the methodology and involves modelling relationships. Establishing relationships among constraints allows reasoning about causal relations among constraints and security concerns such as risk, trust, level of assurance, threats, vulnerabilities, and attacks; as well as considerations regarding trade-off between security and other non-functional requirements.

4. Define abstract policies based on relationships among constraints. Abstract policies include different types of constraints possibly defined by different security entities or actors involved in a given execution.

5. Determine the type of adaptive behaviour to be induced during policy transformation. This will depend on the level of sophistication required for the different abstract policies defined previously and the type of causal relationships among them. There are two types of adaptive behaviour that can be introduced into the system and that may co-exist in a complimentary or combined way at the same time: (a) context-based adaptation: If constraints are used to drive the policy transformation process then they are considered to be context-based adaptive constraints. Typically, context-based adaptive constraints are defined in the form of rules or policies that specify under what circumstances other policies can be combined; and (b) specialisation: If constraints are introduced due to behaviour and are combined during the policy transformation process then they are considered as specialising constraints.

Typically, policy transformation with context-based adaptation is considered to be more complex since it is essentially a context-dependent policy transformation whereas simple specialisation (without requiring to resolve context-based parameters) occurs as a result of behaviour in the execution environment.

6. Define appropriate policy transformation techniques. Again, this depends on the type of abstract policies defined and the level of complexity in their causal relationships. Policy transformation techniques have been classified in two categories: (a) instantiation process: it based on the parameterisation of constraints on a given abstract policy; and (b) integration process: it is based on the mixing of constraints from different abstract policies in order to generate a new abstract or executable policy with the resulting constraints.

In the case of instantiation process, typically the abstract policy to be parameterised defines an execution scope that can be further refined. In terms of scoping it is easier or

181

less complex to verify correctness of the resulting policy in the sense that the base policy already scopes the execution in the first place. In the case of integration process, the resulting scope of execution after applying integration can be reduced but also can be extended in terms of constraints. Therefore it provides more flexibility, but it is more complex to determine how an integrated policy will affect behaviour on the overall system. Similar to the instantiation process technique, the integration process technique can be scoped by having a set of transformation rules as baseline policies defining constraints on how the integration process occurs, for example, as in the case of the protection mechanism of Chapter 4. In addition, in both techniques there can be only simple specialisation, or specialisation plus context-based adaptation depending on the logic behind the corresponding policy transformation process.

An additional aspect to consider is the order in which policy transformation techniques can be applied. Depending on the level of sophistication of the protection system and on the nature of the abstract policies defined it can be necessary to apply several steps of policy transformation. As shown in Figure 60 a fairly complex protection mechanism requires at least two steps: one for instantiation and one for integration of abstract policies. Intuitively, the greater the decomposition/number of policy transformation stages the easier it is to understand and define causal relationships among abstract policies.

7. Define the appropriate policy evaluation process. This process takes as input executable policies. If the executable policies are context-based then contextual information needs to be dynamically resolved and the policy evaluated (context-based adaptation). Therefore, it is important to understand how the protection mechanism implements the evaluation process. In the case of legacy systems, the evaluation module can be too basic or limited on the amount of contextual information that can resolve in which case one option would be to consider externalising the policy evaluation module. Another alternative would be to apply context-based adaptation in the Policy Transformation phase thus influencing the executable policy introduced in the system. In the case of a sophisticated protection mechanism with an existing context-based evaluation module, such as e.g. XACML, it might be more sensible to induce the context-based adaptive behaviour internally. An additional potential scenario is the case in which contextual information needs to be resolved internally as well as externally, or a case in which the evaluation module cannot evaluate a policy. In such cases a protocol is required to pass control back to the policy transformation phase.

8. Define the appropriate monitoring process. This depends on what information or events are or become relevant, and should be monitored. Moreover, as mentioned before the monitoring process can be event-based or query-based depending on whether the process

182

signals events to other processes, i.e. transformation and evaluation processes, or whether the latter require to resolve contextual parameters, respectively.

9. Define the appropriate detection process. This process overlaps with the monitoring process in that it is event-based and communicates with the policy transformation process. However, the main difference is in that it can correlate information and events incoming from the monitoring process, infer non-expected but relevant execution state or context information, and to adaptation strategies to be fed to the policy transformation process. This aspect is mentioned for completeness but is out of scope in this research.

The above described stepwise guidance directly relates to the fundamental research questions and system requirements extracted in chapter 3 and also the research aims of the introductory chapter. The next section presents a discussion on the fulfilment of the system requirements by the proposed framework and stepwise guidance.