Cloud network, whether operated by a single or multiple operators, requires quantifiable security levels. This would ensure that all the actors (application providers, enterprises, business partners, end-users, data centre operators, cloud site operators, and network operators) obtain a better view of the current security grade of the network and are aided in managing their individual application scenarios, business models, usage, storage, and migration policies besides recognizing plausible operational and management risks.
The overall security requirements can be described using a set of parametrizable security goals / objectives. Each security goal must be characterized with respect to the underlying resource(s), and is therefore used to constrain the security parameter(s) of resource(s). It is imperative to start off with parametrizable goals, which can be finally mapped to configurations of underlying resources. For our purpose, we propose to use the terms goals and objectives as synonyms.
From the user side: For each goal, we would have a set of security parameters, for example ge- ographic location, integrated security through Software Development Life Cycle (SDLC) etc. These security parameters may then be mapped on to resource constraints, which describe the resources being constrained to specific values (or ranges), in order to satisfy the respective parameters.
From the operator side: For each security parameter (which has defined the resource con- straints), the operator must select its security mechanism(s), which would be used to implement the desired resource characteristics specified by the user. These mechanisms comprise of security ser- vices which help fulfil the requirements of the individual parameters, i.e., the resource constraints. Once the parameters are constrained to obtain configuration of resources, it would help execute the security parameters, which would help fulfil the respective goals. These steps are performed before virtual resources are moved to an operator side, i.e., before initially placing the virtual resources in CloNe and when moving the virtual resources inside CloNe from one side to another. This process is initiated from the DCP and handed over to the control plane of a single domain.
Figure 7.1: Security mechanisms
The user’s access to all resources needs to be defined by access control policies (see Section 7.7). Favourably, mechanisms for anonymised access to resources is supported by the access control.
The following Figure 7.1 elucidates the hierarchical structure between security goals, security parameters and the resource constraints from both the CloNe user and operators side.
The security framework follows a modular approach to reuse the goals and their translations to the underlying resources. The modules are realized as sub-goals, or security parameters which can be translated into a group of resource constraints. For example, two separate goals, i.e., “Ensure resources are Payment Card Industry Data Security Standard (PCI DSS) compliant” or “Ensure that there is a minimum security level for the involved metrics” might be entirely different, but share a large number of common parameters (sub-goals). Instead of translating the entire goal from scratch, the security goal translation function will have the ability to reuse the modules that have already been translated. Therefore, it would promote scalability and reduce overall complexity. The following subsection describes how the security goals are obtained, both from the user and generated on-the-fly to ease the overall goal translation process.
7.2.1 Obtaining Security Goals
Security goals must primarily be obtained from the customer through an SLA at the DCP. The underlying resource set is dynamic throughout the lifecycle of a requested service, and hence ex- tra care should be taken to keep the goals consistent, irrespective of the implementation of the requested service and utilization of the underlying resources. Security is usually a non-negotiable characteristic and the goals must not be reformulated unless explicitly specified by the tenant or the administrator of the individual domains.
Figure 7.2: Security goal translation
However, it might be possible that the existing goals specified at a specific architecture layer, might not map directly to the security parameters/sub-goals to be implemented at lower layer(s). Therefore, it is imperative that the lower layers must have additional mechanisms to specify secu- rity goals, specific for the resources at that certain layer. For example, if a security goal specified at the distributed control plane doesn’t map directly to the security parameters/sub-goal to be im- plemented at the cross-domain infrastructure layer, a mechanism should be realized to specify ad- ditional security goals specific for the cross-domain layer to implement the desired parameters/sub- goals.
Finally, monitoring procedures have to be put in place to obtain a feedback about the status of the resources. These measurements, carried out at the VM or physical layers shall assist the security goal translation function to release constraints to the resource management function. The resource management function will then enforce the constraints on the resources. The feedback information might also be useful for the user, who might want to reformulate the goals after receiving undesired performance results.
7.2.2 Security Goal Translation
The security goal translation process includes receiving a set of inputs which need to be provided to the overall goal translation function. The overall goal translation function translates the goal(s) in order to generate security parameter(s). These security parameters are used to specify the security characteristics (parameter constraints) of the underlying resources.
The inputs required by the security goal translation function for generating the overall parameter constraints include, but are not limited to:
1. Service requests: The user shall specify the desired behaviour and properties of the requested service through a well-defined user interface. Ideally the constraints described in the service request must map fairly directly to the underlying resource set. Moreover, the tenant shall have the option to modify their requests within the life-time of the agreement of the service request.
2. Monitoring: The measurements carried out at different architecture layers provide a clear picture of the overall functioning of the infrastructure components, and are essential to gauge the status of the resources.
3. Topology: The goals can’t be translated to security services (and further to security parameter constraints) unless the function is aware of the underlying network topology.
The goal translation function as shown in Figure 7.2 should be generic enough to be implemented at any distinct layer, as goals may be specified at any layer, and not only at the DCP. Therefore, its design should be implementable at both the single, as well as the cross-domain infrastructure layers.
Moreover, as the security goal translation function requires input from different management func- tions, it should have an overall generic interface and should use a widely accepted communication mechanism. This would ensure communication between different parameters lying in the same, or different administrative domains.
Finally, it would be safe to state that the security goal translation function is in actuality a subset of the overall goal translation function, which is described in Section 5.2.1. It would be based on the same structure as the overall goal translation function, and would be focusing on generating the security specific configurations of underlying resources for facilitating secure resource management. 7.2.3 Auditing Mechanism
It is equally important to invoke auditing procedures that will check whether the parameter con- straints are being fulfilled or not. The auditing mechanism shall work in a modular fashion, with the respective modules being invoked at repeated intervals. Each module shall audit, assert and assure specific sections of the infrastructure and will have its respective invoking frequency.
An auditing mechanism shall be chosen on the ease of integration into the existing security framework and its ability to be platform and programming language agnostic.