Cloud Management. Description

Transcription

1 B 5.XXCloud Management B 5.XX Cloud Management Description Cloud Computing refers to the dynamic provisioning, use and invoicing of IT services, based on demand, via a network. These services are only made available and used via defined technical interfaces and protocols. The Cloud Management module aims at cloud service providers. It does not make any difference whether you offer your cloud services on an internal (private cloud) or external (public cloud) basis, or which service model (infrastructure as a service, platform as a service or software as a service) you have opted for. The main task of cloud service providers is the cloud management, i.e. the provision, administration and operation of offered cloud services. A cloud computing reference model covering the main aspects of cloud computing is used to describe the operating processes of cloud management. The basis of the module is the reference model (cloud reference framework) of the Internet Engineering Task Force (IETF) which is provided as a so-called internet draft during the preparation of the module. The reference model is structured in layers for cloud services, virtualisation (virtual machines for cloud service operation) and physical components (as carriers for the virtual machines) describing their interaction. These layers are referred to as horizontal layers. Interacting with these layers, the reference model implements cloud management as a vertical layer effecting all horizontal layers. Cloud management in particular includes security (i.e. security management and security safeguards). The typical tasks of cloud service providers in cloud management include: - provision of a service catalogue describing the cloud services offered; - provisioning and de-provisioning, respectively, of cloud resources (including: virtual machines, virtual data memories, virtual networks) and cloud service profiles (defined configurations for cloud resources used to provide the services offered); - allocation of physical and virtual resources to the cloud service users and the configuration of these resources; - access management for cloud resources and the authentication of access; - monitoring of provided cloud services and resources in order to comply with the stipulated quality of service; - billing of the cloud services used (on the basis of the service catalogue) in a traceable way for the customer. A description of the cloud management and its required processes is provided in knowledge safeguard S 4.CM.22 Introduction to cloud management. Cloud management does not only include activities occurring only or mainly with cloud computing but also activities generally involved in the management of IT operations or IT services. These activities include: - security management, - incident management, - system and user management, - network management, - disposal of components and secure deletion/destruction, - contingency planning. Scope of the subject area The module aims at making recommendations for the secure provision, administration and operation of cloud

2 B 5.XXCloud Management services. Useful and appropriate security requirements for the cloud management are developed to protect the provided services and underlying information, applications and systems from within the "cloud". The module mentions concrete and detailed threats and safeguards for cloud management. Wherever cloud management overlaps with the general management of IT operation and IT services (see above), the module is restricted to the areas which are specific for cloud computing. Security aspects in association with the original features of cloud computing are thus the focus of the cloud management module. This mainly includes the particularities of multi-tenant capabilities, the so-called orchestration (generic term for provisioning and de-provisioning) of cloud resources and the automation in the cloud administration. The threats and safeguards of this module are mainly aimed at cloud service providers which provide private cloud services for SMEs and public authorities. The basic security recommendations are also applicable to public cloud services and hybrid cloud services (utilisation of several cloud infrastructures via standardised interfaces); whereby, for this purpose, the cloud usage module must additionally be respected. The module neither covers security safeguards which secure the cloud service itself (please refer to the modules B 5.21 Web applications and B 5.X Web services) or which must be taken by cloud service customers (e.g. formulation of the contract with the cloud service provider). These are security topics of cloud computing which are specified in the cloud usage module. Nor does the module cover the securing of underlying (virtual and physical) IT systems and applications and their administration. Please refer to the corresponding modules, e.g. for virtualisation, network management and storage systems. Threat scenarios Cloud services have a wide range of functions and accordingly a huge number of interfaces. Theses interfaces are targets and starting points for manipulation attempts, in particular if the cloud services are accessible from "external" insecure networks. On the one hand, this results in new organisational deficiencies, technical faults and human errors. On the other hand, the threats for target objects which are not cloud-related but basically required for the rendering of cloud services (i.e. threats for web applications, threats for servers, threats for physical security) must be re-evaluated, taking into account the new facts and features of cloud computing. The following typical threats (T) are assumed for cloud management as regards IT-Grundschutz. Organisational Shortcomings - T 2.CM.01 Incorrect provisioning and de-provisioning of cloud services - T 2.CM.02 Missing support of the manufacturer regarding the provision of cloud services - T 2.CM.03 Inadequate isolation and separation of cloud resources - T 2.CM.04 Inadequate business continuity management at the cloud service provider - T 2.CM.05 Lack of communication with the cloud service customer - T 2.22 Lack of or insufficient evaluation of auditing data - T 2.CM.06 Incorrect planning of cloud service profiles - T 2.67 Incorrect administration of site and data access rights - T Insufficient training of employees - T Poor and inadequate planning when distributing patches and changes - T Lack of or insufficient logging Human Error - T 3.CM.07 Inadequate configuration of cloud services and cloud administration systems - T 3.CM.08 Incorrect automation during cloud management - T 3.9 Improper IT system administration - T 3.36 Misinterpretation of events - T 3.38 Errors in configuration and operation - T Incorrect administration during logging Technical Failure - T 4.CM.09 Failure of administration servers and administration software - T 4.CM.10 Unauthorised restoration of snapshots

3 B 5.XXCloud Management - T 4.CM.11 Incompatibility of cloud administration and administration of cloud elements - T 4.CM.12 Information unintentionally revealed by cloud cartography - T 4.20 Overloaded information systems - T 4.22 Software vulnerabilities or errors Deliberate Acts - T 5.CM.13 Misuse of administrator rights in the cloud management - T 5.23 Malicious software - T 5.28 Denial of services - T Misuse of Spanning Tree Recommended Safeguards To secure an IT system, other modules will need to be implemented in addition to this module. These modules are selected based on the results of the IT-Grundschutz modelling process. Various elements must be taken into account when mapping the cloud infrastructure in the IT-Grundschutz: physical components (hardware), virtualisation server, virtual machines (IaaS) and cloud applications (PaaS and SaaS). The following elements should be taken into account for cloud management modelling: - Physical components (hardware): For the cloud infrastructure hardware (such as servers and connected storage systems), the appropriate basic IT modules of layer 3 must be used (e.g. B General server or B Storage systems and storage networks). - Virtualisation server: Module B Virtualisation must be applied to each virtualisation server or each group of virtualisation servers. A virtualisation server is a physical IT system (client or server) where virtual IT systems are operated. In addition to module B Virtualisation, each relevant server or client module of layer 3 should be applied to the virtualisation servers. The Cloud Management module is modelled on the server for the administration software of the cloud infrastructure. - Virtual machines: Virtual IT systems (virtual machines, VMs) are modelled by means of the modules from the IT Grundschutz catalogues. VMs are basically modelled in the same way as physical IT systems, i.e. each relevant module of layer 3 and 5 is used. In practice it is often the case that many VMs are modelled. Useful VM modelling is therefore often only possible by forming suitable groups. - Cloud applications: Cloud applications are mapped by the relevant modules of layer 5 in relation to the corresponding virtual machines. Here, modules such as B 5.7 Databases, B 5.4 Web servers or B 5.21 Web applications are modelled. Further information regarding the modelling of virtual IT systems is provided in the safeguard S 2.CM.05 Modelling of cloud management (W). Planning and design A set of prevailing conditions must be observed when planning the environment for cloud computing. On the one hand, the physical and virtual IT infrastructures for efficient provisioning must be planned. Suitability, compatibility and easy administration must be taken into account when selecting components (S 4.CM.01 Planning of resources for cloud services). On the other hand, cloud service profiles must be developed. Cloud service profiles are defined in one set of information which describes the cloud resources and their configuration. The (automatic) scalability of cloud service profiles must be particularly taken into account (S 4.CM.02 Planning of cloud service profiles). Procurement For the selection of the hardware for cloud environments, it is particularly important to procure systems which are suited for the trouble-free cooperation of virtualisation solutions, hardware and cloud administration software. The systems must have enough power (processing power, operational capacity, response times) with which to provide for all cloud services accessed by the cloud service customers at the agreed times (S 4.CM.06 Selection of cloud components). Implementation After having completed planning and procurement, the cloud components must be correctly configured.

4 B 5.XXCloud Management Access paths are additional components of the cloud infrastructure. In most cases, the access to cloud offers are web-based via insecure networks. These access paths must therefore be secured in the cloud management (S 5.CM.08 Protection of communication to cloud access) Before offering cloud services, the responsible administrators must be trained for the secure operation of cloud components (S 3.CM.11 Training of the administrators of cloud infrastructures). Operation For the operation of cloud services, the cloud management is responsible for provisioning and de-provisioning, automation, the separation of clients and the monitoring of cloud resources. During the operation of cloud services, the cloud management ensures the correct and efficient setting of the cloud infrastructure and services. An important part in this context is the controlled orchestration, i.e. the provisioning and de-provisioning of cloud resources (S 2.CM.19 Controlled provisioning and de-provisioning of cloud services). In this connection, the cloud components are configured and the configuration settings are regularly controlled. Automation brings about a high degree of flexibility and operational facilitation but at the same time involves significant damage potential in case of incorrect configuration in the cloud administration software. Therefore it is necessary to provide and carry out effective controls (S 2.CM.21 Secure automation of cloud control processes). The central requirement for cloud offers is the "separation of clients", i.e. the safe separation of users, IT systems and data of different cloud service customers. Such security safeguards for separation are set up at different levels of the IT-Grundschutz (e.g. network, storage networks, virtualisation) and therefore also implemented by means of the modules of other layers. The cloud management must ensure that the overall separation of clients works correctly and consistently for all components of the cloud infrastructure (S 4.CM.16 Consistent separation of clients of cloud services). Since the cloud infrastructure is highly integrated and has a central cloud management, it is necessary to introduce central logs and implement module B 5.22 Logging. The specific safeguards for the logging and monitoring of cloud resources, cloud performance and the utilisation of cloud services must be observed (S 4.CM.14 Logging of events in the cloud infrastructure). On the one hand, the cloud service provider must control the utilisation and use of his resources in order to identify possible bottlenecks, on the other hand, he must provide proof of the promised performance to the cloud service customers (S 2.CM.20 Reporting and communication to the cloud service customers). Contingency Planning The contracts between cloud service customers and cloud service providers include agreements regarding the quality of service (availability periods, downtimes). In order to ensure this quality of service, cloud management also involves contingency planning. The contingency planning for cloud offers includes certain virtualisation mechanisms (e.g. high availability), physical and network-based redundancies and standard data backup and restoring processes. Existing contingency planning components of the cloud service provider, also from other parts of his IT operation, may be adopted for cloud management; if necessary, cloud-specific parts must be added (S 6.CM.23 Contingency planning and regular data backup in cloud computing). The bundle of security safeguards relating to the cloud management are presented in the following. Planning and design - S 4.CM.01 (A) Planning of resources for cloud services - S 4.CM.02 (A) Planning of cloud service profiles - S 2.CM.03 (Z) Provision of security policies for cloud service customers - S 2.CM.04 (A) Contractual arrangements with third-party services providers - S 2.CM.05 (W) Modelling of cloud management Procurement - S 4.CM.06 (A) Selection of cloud components

5 B 5.XXCloud Management Implementation - S 4.CM.07 (Z) Virtual security gateways (firewalls) in clouds - S 5.CM.08 (A) Securing the communication to the cloud access - S 4.CM.09 (Z) Encrypted storage of cloud service customer data - S 4.CM.10 (Z) Multi-factor authentication for cloud service user access - S 3.CM.11 (B) Training for the administrators of cloud infrastructures - S 5.71 (C) Intrusion detection and intrusion response systems Operation - S 2.CM.12 (C) Use of a highly-available firewall - S 4.CM.13 (C) Central protection against malware in the cloud infrastructure - S 4.CM.14 (B) Logging and monitoring of events in the cloud infrastructure - S 4.CM.15 (A) Patch management for cloud components - S 4.CM.16 (A) Consistent separation of clients from the cloud services - S 2.CM.17 (A) Controlled administration of users and authorisations in cloud computing - S 2.CM.18 (C) Secure and complete deletion of cloud service customer data - S 2.CM.19 (A) Controlled provisioning and de-provisioning of cloud services - S 2.CM.20 (B) Reporting and communication to the cloud service customers - S 2.CM.21 (C) Secure automation of cloud control processes - S 4.CM.22 (W) Introduction to cloud management - S 2.38 (B) Division of administrator roles - S (A) Analysing the logged data Contingency Planning - S 6.CM.23 (A) Contingency planning and regular data backup in cloud computing - S 6.CM.24 (C) Use of redundant cloud management components - S (A) Alarm concept for the logging function

6 T 2.CM.01 Incorrect provisioning and de-provisioning of cloud services T 2.CM.01 Incorrect provisioning and de-provisioning of cloud services During the operation of cloud services, the cloud management ensures the correct and efficient configuration of the cloud infrastructure and services. An important part in this context is controlled orchestration, i.e. the provisioning and de-provisioning of cloud resources. The compilation of cloud resources (main memory, CPU, storage, virtual networks, etc.) and their configuration (set-up of virtual machines, etc.) is the basis for the provision of cloud services. This basis is also referred to as cloud service profile. Cloud resources are thus provisioned and de-provisioned by the orchestration of cloud services. Threats within the framework of the provisioning and de-provisioning of cloud services result from planning and conception errors. If the cloud services lack the promised properties and qualifications, you speak of inadequate provisioning and de-provisioning. Inadequate provisioning and de-provisioning is manifested in the incorrect allocation of cloud resources and in the incorrect allocation of cloud service profiles. Examples: - If the required resources for the cloud service profiles are not adequately planned, the operation of the cloud infrastructure is at risk. This can be traced back to deficiencies in the requirements management. The incorrect or inadequate inclusion of cloud service requirements may result in the incorrect provision of cloud services and the associated incorrect provisioning of cloud resources. - The implementation of provisioning processes is not checked in the components used for the provision of cloud resources (the so-called cloud element manager or in short the element manager). Thus, provisioning is not adequately tested. - If cloud resources are incorrectly prioritised, the cloud infrastructure is overloaded during "peak times", e.g. for end-of-month accounts. - Virtual systems for cloud services are equipped with sufficient memory and CPU, however the external connection to cloud service customers is not adequately dimensioned. Page 6 of 98

7 T 2.CM.02 Missing support of the manufacturer regarding the provision of cloud services T 2.CM.02 Missing support of the manufacturer regarding the provision of cloud services Only rarely do cloud service providers take the responsibility for all cloud applications, products or platforms or develop them autonomously. A more frequent constellation is that cloud service providers provide third-party applications or products in the cloud, or base their cloud services on third-party products. The utilisation of third-party products and solutions involves the risk for cloud service providers that the cloud services offered are affected by the dependency on third-party components or products. This can result in various risk scenarios for the cloud services which can arise in association with missing manufacturer support (i.e. support of third parties involved). Incorrect security settings carried out by third-party manufacturers The cloud service provider carries out all required configurations for cloud services based on the applications of third-party manufacturers. The configurations of third-party applications are associated with security settings. This creates the risk that third-party manufacturers do not refer to the required security configurations, or do not adequately support the cloud service provider in the implementation of security settings. If only third-party manufacturers are allowed to make security settings due to reasons of warranty, the cloud service provider risks the incorrect configuration by the third-party manufacturer. This is, for example, the case if the cloud service provider buys an application with security-relevant configurations (such as the selection of an adequately secure encryption algorithm) which are only possible with the support of the software manufacturer. Restricted compatibility of third-party cloud components used It might be that cloud services which are based on third-party applications are not compatible with the basic cloud infrastructure. In many cases, the manufacturer enables applications for a certain combination of operating systems and hardware platforms. A cloud application, for example, may be enabled by a third-party manufacturer only for a certain version of the Windows operating system, and the manufacturer will only provide support if these compatibility standards are complied with. This creates the risk that in case of vulnerabilities or application errors, the manufacturer won't provide any support, or that troubleshooting is only possible if the underlying platform is changed. This might impair the service level and at worst prevent the elimination of vulnerabilities. Error-proneness due to the lacking use of standardised formats Due to the variety of cloud offers and the variety of virtualisation solutions, there are only few established standards of virtual IT systems or secure cloud service profiles. Virtualisation manufacturers support inconsistent open formats (e.g. Open Virtualisation Format OVF). Without standardised formats, it is difficult for cloud service providers to use the trouble-free and secure packing and distribution of virtual machines and cloud service profiles. Consequently, the cloud service provider must carry out many configurations Page 7 of 98

8 T 2.CM.02 Missing support of the manufacturer regarding the provision of cloud services and operations in the cloud management for the distribution of cloud services. This makes the cloud configuration management process more prone to errors. Page 8 of 98

9 T 2.CM.03 Inadequate isolation and separation of cloud resources T 2.CM.03 Inadequate isolation and separation of cloud resources The provision of cloud services for different cloud service customers (clients) from a common and distributed cloud infrastructure is a main feature of cloud computing. The commonly used cloud infrastructure creates the risk that one cloud client has unauthorised access to or view of the information of other clients. The unauthorised reading of information, the deletion of data or the unintended or wilful manipulation of data may cause damage for cloud service providers or cloud service customers. Examples: - The incorrect planning and configuration of different components of the cloud infrastructure may be the reason for inadequate isolation. - The separately used storage resources in the memory may be inadequately separated which creates a risk for the consistent isolation of the cloud. - Inadequate isolation may occur if services are commonly operated on one virtual machine, or if shared storage areas are used. - The inadequate isolation of cloud resources may be caused by incorrect network separation, e.g. if shared network segments are used for different cloud clients. - The separation of cloud resources is inadequate if cloud service customers use a shared database, and if they can read the data of other clients due to inadequate separation on database level. Page 9 of 98

10 T 2.CM.04 Inadequate business continuity management at the cloud service provider T 2.CM.04 Inadequate business continuity management at the cloud service provider Experience shows that malfunctions and accidents, even major ones, cannot be completely ruled out for IT systems. Omissions in business continuity management will very soon have severe impacts on cloud management because many cloud resources, cloud services and cloud service customers (clients) may be affected. Inadequate business continuity management may significantly worsen the problems resulting from malfunctions and accidents in the cloud infrastructure, increase downtimes and thus increase the losses in productivity for the cloud service provider in case of emergency. Beyond the actual emergency, inadequate business continuity management may impair the mutual trust between cloud service customer and cloud service provider which may finally result in the termination of the service agreement. Inadequate business continuity management manifests itself in inadequate coordination and an unstructured approach of the troubleshooting of arising problems. Inadequate business continuity management can manifest itself in disaster recovery or in business continuity management or in both. Examples: - Missing definition of basic parameters for business continuity management, in particular of maximum tolerable outage (MTO), recovery time objective (RTO), recovery point objective (RPO) for the cloud infrastructure or cloud services. Thus, reliable planning for an effective and proper approach in case of emergency is not possible. - Missing, inadequate or outdated contingency plans for the cloud infrastructure or for cloud services - Not tested contingency plans for the cloud infrastructure or for cloud services Deficiencies in contingency planning may have many different aspects as illustrated in the following typical examples: - Responsibilities for business continuity management in the cloud infrastructure or in cloud services are not or insufficiently controlled - Persons responsible for business continuity management in the cloud infrastructure or in cloud services are not nominated - Communication paths for business continuity management in the cloud infrastructure or in cloud services are not defined - No communication between the cloud service provider and the cloud service customers in case of crises - Ways of escalations and decisions for business continuity management in the cloud infrastructure or in cloud services are not defined - Ways of escalations and decisions for business continuity management in the cloud infrastructure or in cloud services are not observed - Option for emergency operation in the cloud infrastructure or in cloud services not or insufficiently provided - A lack of alternative capacities for the cloud infrastructure - Lacking, incomplete or incorrectly defined planning regarding the use of alternative capacities for the cloud infrastructure, in particular the Page 10 of 98

11 T 2.CM.04 Inadequate business continuity management at the cloud service provider connection with an alternative data processing centre. This may primarily occur if there is no prioritisation or an incorrect prioritisation of cloud services for connection, or if dependencies which require a certain order were not defined or observed. - Lacking or inadequate immediate safeguards for business continuity management in the cloud infrastructure or in cloud services - Lacking or inadequate disaster recovery scripts for the cloud services - The absence of cloud administrators cannot be compensated because operation instructions were not documented. This may primarily occur if administrators do everything "by heart" and do not plan that they might not be available sometimes. - Data backup of the cloud services or the underlying infrastructure is not updated. This may primarily occur if backup cycles or storage periods are incorrectly defined or not defined at all. - Data backup of the cloud services or the underlying infrastructure is incomplete. This may primarily occur if the successful completion of data backups carried out is not checked. - The recovery of cloud services from the data backup was not successful. This may primarily occur if data backups failed, or if recovery fails. - Missing, inadequate or incorrect restart plans for the cloud infrastructure or for cloud services - Missing, inadequately or incorrectly defined prioritisation of cloud services for restart - Missing, inadequately or incorrectly defined order for the restart of the cloud infrastructure or the cloud services Page 11 of 98

12 T 2.CM.05Lack of communication with the cloud service customer T 2.CM.05 Lack of communication with the cloud service customer The use of cloud services requires the comprehensive communication between cloud service provider and cloud service customer. Due to the fact that the cloud service customer receives external services and that associated security management activities might be outsourced, a close coordination between both parties is necessary. A lack of communication with the cloud service customer may occur in different phases and processes which may have various negative impacts. This is illustrated in the following examples. Examples: - Lack of communication during planning and commissioning Lack of communication and agreement between the participating parties may have extensive negative impacts on performance, in particular during the planning and commissioning of the cloud services. Not communicating and considering various requirements during this phase will result in different problems with the services to be provided. This may result in considerable additional costs on both sides, for example due to contractual modifications, additional security safeguards, additional audits or possibly even legal consequences. - Lack of communication regarding the compliance with the service level If it is not possible to provide the cloud service customer with the proof of the service level due to a lack of communication or undefined communication interfaces, it is not possible to provide doubt-free proof of the correct performance in case of disagreements, which in turn will endanger correct billing. - Inadequate or not communicated parameters regarding the service level could mean that the cloud service provider will exceed or not fulfil the agreed requirements unnoticed. Thus, inefficient resource allocation may remain unnoticed by the cloud service customer and the cloud service provider. - Lack of communication in security incident management interfaces might be unknown or contact persons cannot be contacted outside the office hours due to a lack of communication within the framework of fault management or security incident management. This may result in significant delays in the processing of malfunctions and incidents. Page 12 of 98

13 T 2.22Lack of or insufficient evaluation of auditing data T 2.22 Lack of or insufficient evaluation of auditing data Functionalities designed to log certain events regarding their chronology are integrated into many IT systems and applications. This way, large amounts of auditing data are often generated in an information system the evaluation of which is complex and very time-consuming. However, reasonably evaluating this auditing data is necessary in order to be able to perform error analyses and to identify attempted attacks. A variety of logging concepts will be used during the life cycle of an IT system. For example, comprehensive logs are created during the development phase in order to facilitate problem analysis in the event of errors. In the implementation phase, logs are used to optimise the performance of the IT system in the production environment or to examine the effectiveness of the security concept in actual practice for the first time, amongst other things. In the production phase, logs are mainly used in order to ensure proper operation. Auditing data is then used to subsequently identify security violations within the IT system or attempted attacks, amongst other things. Logging can also be used to determine who the perpetrator was and can serve as a deterrent to potential attackers as a consequence. Regular evaluation of the auditing data allows for use of the data for preventive measures such as an early warning system, whereby deliberate attacks to an IT system may be detected or defeated prematurely. Central logging If auditing data is evaluated at a central location, it is possible that important information is overlooked and attacks are not detected due to the large amount of data, for example. For this reason, there are systems supporting the administrator in evaluating the auditing data or even automatically evaluating the data. Depending on the product, the information of the different data sources can be combined and processed to become one log report. However, there is the risk that the auditing data possibly can no longer be traced back to their original data source so that it cannot be instantly seen where the event initially occurred. Improperly configured filter functions of the evaluation tools may cause further evaluation issues. This may result in auditing data required for failure detection, troubleshooting, or early warning not being evaluated. Examples: - An attacker tries to crash the database server by means of a DoS attack. This attack is logged on the affected IT system. However, due to a lack of evaluation of the auditing data the attack is not detected and the attacker can repeat the DoS attack until it is successful. - Within the framework of a web server attack, an RPC security gap was used in order to gain access to the system. The web server generated corresponding auditing data, but this data was discarded due to improper filter settings at the central logging server. Therefore, no automatic alarm was triggered and the attack was not detected. Page 13 of 98

14 T 2.CM.06 Incorrect planning of cloud service profiles T 2.CM.06 Incorrect planning of cloud service profiles Cloud service profiles consist of a set of information defining the cloud resources (e.g. memory, CPU, storage) and their configuration for the provision of the cloud service. If the cloud service profiles are badly planned, the promised performance of the cloud service is not possible or is inhibited. Cloud service profiles are badly planned if the configuration of the profiles or the allocated cloud resources do not allow for or inhibit the promised performance of the cloud service. The same effect is caused by cloud service profiles which are not checked. Examples: - Via a static path, there is a reference to a storage system in the configuration of a cloud service profile. The access to this storage area is restricted on the basis of source addresses. The reproduction of the cloud service generates another source address, and there is no more access to the cloud storage. In this example, the configuration and the data model of the cloud application are incorrect and not designed for the scalable automation of cloud services. - Cloud service profiles are not adequately tested. As a result, the cloud services are provided incorrectly or in a quality which was not agreed. Page 14 of 98

15 T 2.67Incorrect administration of site and data access rights T 2.67 Incorrect administration of site and data access rights If the assignment of site and data access rights is controlled poorly, this may quickly result in serious security gaps, e.g. due to chaotically assigned rights. In many organisations, the administration of site and data access rights is an extremely labour-intensive task, because it is controlled poorly or the wrong tools are used. For example, this may require comprehensive "manual work", which in turn is very susceptible to error. Furthermore, this process frequently involves a host of different roles and groups of persons so that the tasks performed are also easily lost track of. Moreover, there are organisations without any control regarding all users and their assigned rights configured on the different IT systems. This typically leads to finding accounts of users who have left the government agency and/or the company long since or who accumulated too many rights due to different activities. If the tools for the administration of the site and data access rights were poorly chosen, they will often lack the flexibility to adapt to changes in the organisational structure or to migrations to other IT systems. The roles of the users may have been separated improperly, which may then result in security gaps, for example by incorrectly assigning users to user groups or granting users rights that are too extensive. Users may have been assigned roles that do not correspond to their tasks (too many or too few rights) or which they should not have due to the tasks they perform (role conflicts). High amount of work Control is lost Improper assignment of roles Page 15 of 98

16 T 2.103Insufficient training of employees T Insufficient training of employees IT users of all kinds often do not receive enough training in the operation of the IT systems they use. Unfortunately, this also often applies as well as to administrators and those providing user support. Expensive systems and applications are frequently purchased without providing enough resources, if any at all, to train the IT users. This may result in serious security problems in case of unintentional user errors, incorrect configurations, and unsuitable operating resources. In many cases, users will not use recently installed security programs because they do not know how to operate them and learning how to use them by themselves parallel to their daily work routine is often considered to be too time-consuming. For this reason, it is not enough by any means just to purchase and install the security software. Examples: - An unknown error message appeared on the screen while a user was entering data. Since clicking "OK" for error messages had never caused any damage so far, the user also selected "OK" this time. However, this time it caused the system to shut down and a loss of all data entered up until then as a consequence. - An expensive firewall system was purchased. The administrator of another IT system was appointed to be the administrator of this firewall system. Since this person was considered indispensable and all available funds were used to purchase the system, he did not receive any training on the operation of the system platform or on the type of firewall used. Requests for external seminars were rejected due to a lack of funds, and the organisation did not even purchase any additional manuals. Two months after starting operation of the firewall system, it was discovered that internal systems were freely accessible from the Internet due to the incorrect configuration of the firewall. - A company was preparing to migrate to a new operating system. The employee responsible for this had expert knowledge of the platform used up until then, but was not familiar with new systems being discussed and was not provided with the corresponding training either. For this reason, he visited some free events held by a manufacturer, whose products he then favoured. This resulted in a poor and costly decision to introduce an unsuitable product. - To use the Internet during business trips, personnel firewalls were installed on the notebooks of the employees. The employees were not trained as to how to adjust the settings of the firewall to meet their needs. As a consequence, many employees then disabled the firewall so they could visit any Internet site they needed without any problems. The result was that many of the computers were infected with malware after just a few weeks. In addition to losing data, the organisation's image was also seriously damaged because s containing malware were sent by the organisation to its customers. - An organisation decides to establish its own cloud infrastructure and provides different applications as cloud services. These cloud services are intended for the provision of internal organisational units only, each of which is to be set up as a cloud client. The IT system administrators also assume the administration of cloud services and of the Page 16 of 98

17 T 2.103Insufficient training of employees administration systems of the cloud infrastructure. Due to a lack of time, the administrators were neither trained on the administration systems for the cloud infrastructure nor for the administration of virtual IT infrastructures. Due to a lack of knowledge necessary for the correct configuration and associated planning, the clients were not separated during the VLAN configuration and the allocation of separate storage areas. After the commissioning of the cloud services, the organisation found out that all employees had access to the cloud storage of the HR department which was not separated from the other clients. Page 17 of 98

18 T Poor and inadequate planning when distributing patches and changes T Poor and inadequate planning when distributing patches and changes To ensure that patches and changes can be distributed in the organisation within the defined period of time, the technical and personnel resources required for this purpose must be planned in the framework of the patch and change management. If no adequate resources are available, there is the risk that the distribution of changes takes more time than planned or even fails. Thus, business processes with high availability requirements might be impaired if, for example, servers or databases required for this purpose fail. Patches and changes may also be distributed in a software-based manner. If the software used for this purpose, however, cannot be adapted to the growing and ever more complex IT landscape, the distribution ultimately becomes more time-consuming. Therefore, it is no longer be possible to distribute security updates promptly. Sometimes, the order in which patches and changes have to be distributed are relevant for the consistency and security of the entire system. For example, a new version of a security software program might require an operating system on which all current patches have been installed. In this case, first the operating systems in the information system must be updated, restarted if necessary and only then can the new security software be installed. A distributing software that does not check the existing patches and changes might try to install the security software before the operating system has been updated successfully. Thus, it would leave an inconsistent or even unpatched system. If the software on IT systems is updated, it is often necessary to restart the application or the operating system afterwards. It takes some time until complex applications such as databases make their data available again following an update. During this period of time, the applications and data of the systems are not available. For systems with high availability requirements, this can have a negative impact on the organisation. This is particularly the case when the systems are not available for a longer period of time than expected due to errors during the change operation. Such failures might mean that employees or customers are impaired in carrying out their work. Examples: - In on organisation, a security patch for a Windows server is installed. This server must be restarted afterwards. During this period of time, the system is not available. Since the login process to the internal LAN runs on this server, the users cannot log in or carry out their work only work to a limited extent during this period of time. With its customers, the organisation has agreed upon a high level of availability by means of Services Level Agreements and thus violates existing contracts. - The IT department of a company installs a security patch on a Voice over IP server. When restarting the system, the configuration file of the VoIP service must still be adapted in addition to this. During this period of time, it was not possible to answer external telephone calls. The company's lack of availability has a negative effect on its external perception by its customers. Page 18 of 98

19 T 2.160Lack of or insufficient logging T Lack of or insufficient logging Logged data can be used, for example, in order to determine whether security specifications were violated or whether attacks were attempted. Additionally, the logged information can be used for error analysis in the event of damage and for determining the causes or for integrity tests. Within an information system, there are often IT systems and applications for which the logging of the basic settings has not been enabled. Such systems and applications must be configured accordingly in advance. Logging may not be possible for systems and applications. An insufficient planning concept may also cause a lack of logging. Even if logging is used for individual systems, information and findings resulting from this may be lost, because they are not collected at a central location. In information systems without centralised logging, it is difficult to ensure that the relevant logged information of all IT systems is maintained and analysed. If the users of the IT systems and applications are allowed to disable the logging function themselves, this may also cause problems. For example, a user may violate policies without this having any consequences for him/her. If the users are allowed to change or delete existing log files, there is the risk that security violations are not detected. Example: - An unauthorised user tries to guess passwords for the web account of other users. Since the password can often be used for other services (single sign-on), this is particularly interesting for the attacker. This attack is not detected due to a lack of logging on the server. The attacker can guess the passwords of the users unobtrusively by using the brute-force methods. Page 19 of 98

20 T 3.CM.07 Inadequate configuration of cloud services and cloud administration systems T 3.CM.07 Inadequate configuration of cloud services and cloud administration systems The cloud administration consists of the settings of the administration systems for virtualisation and for the cloud. The multitude of cloud components to be administered make the changes, which must be consistently implemented for all systems, complex and error-prone for the administration in the cloud management. In particular human error of persons which work in the cloud administration may result in inadequate configurations after incorrect entries in the administration system. Inadequate configuration of cloud services Due to human error, the confidentiality, integrity or availability of cloud service information might be at risk as a result of their inadequate configuration which might be the allocation of cloud resources to a cloud service, or incorrectly granted authorisations. If inaccurate cloud service profiles are used, such inadequate configurations will effect all cloud services based on these profiles. Inadequate configurations of the cloud administration systems Whenever cloud services are automatically configured via the cloud administration software, there is a risk that the configurations are incorrectly implemented, if at all, for each administration component (the so-called element manager) of the cloud infrastructure. This might be caused by errors in the configuration datasets to be implemented or by the incorrect transmission or implementation of the element manager. Examples: - A virtual machine (as part of a cloud infrastructure) is allocated to the wrong security zone. - A virtual machine (as part of a cloud infrastructure) is allocated to the wrong client. - There is a faulty configuration in the cloud administration regarding the allocation of administration servers to virtual storage networks (so-called VSAN). As a result, there are no storage resources available for the virtual machines of the administered cloud services. Page 20 of 98

21 T 3.CM.08 Incorrect automation during cloud management T 3.CM.08 Incorrect automation during cloud management The properties of cloud computing solutions require the automation of routine tasks for the flexible and demand-oriented provision of resources. The orchestration automation is an important feature of cloud computing solutions. Automation is the multiplication of cloud services on the basis of cloud service profiles. Automation is considered as incorrect if, during the reproduction of a cloud service, the automated provision of required cloud resources (virtual machine, memory, CPU, hard disk capacity) is insufficient for the provision of the cloud service with the promised properties. Incorrect automation may have technical causes. This is the case if the configurations for automated provisioning and de-provisioning are not implemented at the technical cloud components. Incorrect automation may have more severe impacts than individual manual configurations. Incorrect automation involves major damage if the use and allocation of resources via automated processes is not restricted by policies. The lack of prioritisations and limits defined for the cloud resources of each cloud service may cause resource bottlenecks or the waste of resources. Examples: - For each cloud service customer, 4 GB of storage space must be provided for each cloud application. By mistake, a value of 400 GB for each cloud service customer is entered in the policy for the automated provision of cloud applications. If this cloud application is provided by an automated procedure, it will soon be impossible to provide storage space for a lot of the clients. - In case of the automated provisioning of cloud resources, the configurations are forwarded to an administration system for memories. However, this administration system is not available; consequently, neither the configuration is implemented nor is an error message issued. Page 21 of 98

22 T 3.9Improper IT system administration T 3.9 Improper IT system administration Improper IT system administration can place the security of an IT system at risk when it results in the disregarding or bypassing of security safeguards. An example of improper administration is when network access capabilities are created (or not disabled) that are not necessary for the proper operation of the IT systems or that represent a particularly serious threat due to their tendency to contain errors. A problem frequently encountered is that the user names used to work on the IT system are granted more privileges than are absolutely necessary for the tasks at hand. If a computer becomes infected with a computer virus or a Trojan horse in this case and the user works with administrator rights, there may be wide-ranging consequences since the malware will also run with administrator rights. Incorrectly installing new or existing software can create security problems. It is very uncommon for standard installations of operating systems or system programs to offer all the features required for a secure configuration. Improper modifications to meet the actual security requirements can pose a considerable risk in this case. The danger of configuration errors is especially serious in complex security systems such as RACF under z/os. Many system functions have a mutual influence on each other. Special attention must be paid to systems that, when poorly administrated, could affect the protection of other systems (e.g. routers and security gateways). Every modification to the security settings and every extension of access rights constitutes a potential threat to the overall security. Examples: - When user IDs not needed any more are not deactivated, it is common for no one to take care of their privileges and contents. If an attacker is able to gain access to an unused user account, then he may be able to access internal information and applications using this account. - Other examples of incorrect administration include the failure to use logging capabilities or to analyse existing log files, granting access rights too generously and then failing to review the access rights at regular intervals, multiple assignment of the same login name or UID, and the failure to use the security tools available, e.g. failure to use the shadow file for passwords in Unix. - The effectiveness of a password decreases as it gets older. The reason for this is that the probability of a successful attack increases steadily over time. - In a z/os system, the user files were protected using RACF profiles via Universal Access so that no one was able to access them unchecked (UACC = NONE). Due to carelessness on the part of the administrator, an entry in the Conditional Access List of the profile granted READ access to all IDs (* entry). As a result, every user in the system could see the files via the Conditional Access List even though UACC=NONE was specified. Page 22 of 98

23 T 3.36Misinterpretation of events T 3.36 Misinterpretation of events When using a management system, the respectively responsible system administrator is responsible for analysing and interpreting the messages of the management system in order to then initiate suitable safeguards. In general, the messages of the management system are based on monitoring mechanisms automatically searching through system logs of various types according to certain rules. In this, it is not easy to automatically detect anomalies indicating system errors in the profusion of log data generated and to then send the corresponding messages to the system administrator. In fact, errors can even remain undetected. For this reason, the incoming messages always need to be read and interpreted by the system administrator, since the messages (in case of an error) are based on the error symptoms and their (automatic) interpretation. A system administrator must also be able to recognise false alarms and incorrect error messages. If system messages are interpreted incorrectly by the administrator, then supposedly corrective countermeasures could even make the situation worse under some circumstances. Page 23 of 98

24 T 3.38Errors in configuration and operation T 3.38 Errors in configuration and operation Configuration errors arise when programme start-up parameters and options are set incorrectly or incompletely. This includes, for example, access rights that are specified incorrectly. When a user makes an operational mistake, not only individual settings may be incorrect, but the IT systems or applications may also be handled incorrectly. An example of this is starting programmes that are not necessary to fulfil the function of the computer, but can be misused by an attacker. Examples of configuration or operator errors nowadays are storing passwords on a PC on which untested software is run off the Internet or loading and implementing malicious ActiveX controls. These programmes, which amongst other things are used to make web pages more attractive using dynamic content, are run with the same permissions as those possessed by the user. They can delete, change, or send any data desired Many programmes intended to be used for publishing information in an open environment without restrictions can, when configured incorrectly, provide potential attackers with data that they can then misuse. In this manner, for example, the finger service can inform an attacker of how long a user has already been sitting at a computer. Browsers also transmit a substantial amount of information to the web server (e.g. the versions of the browser and operating system used, the name(s) and the Internet address of the PC) whenever a query is issued. Cookies should also be mentioned in this context. These are files on the user s computer in which the operators of web servers store data relating to the web user. This data can be called up the next time the server is visited and can be used by the operator of the server to analyse which web pages on the server the user has already visited. The use of a Domain Name System (DNS) is a further source of danger. On the one hand, an incorrectly configured DNS makes it possible to query a large quantity of information relating to a local network. On the other hand, an attacker can send forged IP addresses by taking over the server, enabling the attacker to control all data traffic. Automatically executable content in s or HTML pages is another serious threat. This is referred to as a content security problem. Files downloaded from the internet can contain code that is executed simply by being viewed, without confirmation from the user. This is the case, for example, with macros in Office files, and this capability is exploited to create so-called macro viruses. Even programming languages and programming interfaces such as ActiveX, JavaScript or Java, which were developed for applications on the Internet, also have the potential to cause damage if the control function is implemented incorrectly. In z/os operating systems, the availability of the RACF security system is of primary importance to the availability of the entire system. The availability could be restricted through improper use of z/os utilities when backing up the RACD database or by using the RACF commands incorrectly. Page 24 of 98

25 T 3.114Incorrect administration during logging T Incorrect administration during logging If logging servers are administrated incorrectly and security incidents are not recognised or discovered as a consequence, the security of the entire information system may be adversely affected. Configuration and operation errors are possible causes. Such administrator errors may additionally cause a loss of confidentiality of data requiring protection. The configuration errors include incorrectly or incompletely configured parameters and options. This may be a threshold set too high, the exceeding of which generates an alarm, or filter settings that are too tolerant. Such misconfiguration may trigger frequent false alarms making premature warning more difficult. Operation errors in the field of centralised logging may occur if the training measures are insufficient or non-existent. This may result in the administrators misinterpreting the analysis results of logged data and therefore overlooking a security incident. Improper operation may also result in logged data being deleted or changed accidentally. Another potential risk for the overall security is entailed by modified security settings and advanced access rights for the logging system. These may be exploited by unauthorised users in order to gain access to the monitored IT systems. Examples: - Within an organisation, the utilisation thresholds were set too low within the early-warning system. For this reason, a false alarm is triggered even when the server is only slightly utilised. Over the course of time, the alarms are neglected more and more and ultimately disregarded completely. This results in a high security risk, because real alarms indicating that the server actually is strongly overloaded are now ignored as well. Due to the overload condition, a server fails for a longer period of time and causes huge financial damage. - An administrator accidentally changes the time of a login event from 07:13 am to 77:13 in one of the log files by entering an incorrect command in the text editor only controlled by the keyboard. Later, this log file is required in order to demonstrate that a user logged in to his computer at 07:13 using his user name on 14 April Due to the invalid time, the entry in this log file is of no use. Since the event cannot be found in any other log file, it cannot be demonstrated that the employee was at work this day at this time. Page 25 of 98

26 T 4.CM.09 Failure of administration servers and administration software T 4.CM.09 Failure of administration servers and administration software Several virtualisation servers and, if necessary, also several servers for cloud administration are used for the cloud IT infrastructure. The failure of one administration server of the cloud does not necessarily directly effect the availability of all cloud services because the virtualisation components will continue their operation autonomously even without administration. If, however, the administration servers for the cloud fail, almost all cloud management processes will be effected directly or indirectly such that many or all of the functions of cloud management will fail. Modifications to the configuration are no longer possible, and automated orchestration processes are no longer available. This failure also effects the availability of the administrative interfaces. During the period of administration server failure, the cloud administrators can neither respond to occurring problems nor integrate new cloud resources (physically and virtually) into the cloud IT infrastructure. Example: - If the administration server or its monitoring component delivers improper data or no data at all, the administrators can no longer adequately monitor the function of the cloud infrastructure. Resource bottlenecks in the virtual infrastructure are not identified, and the virtual infrastructure cannot be extended in a timely manner. Neither can the failure of individual cloud components be identified in due time if the monitoring component has failed. Data storage and working memory are exhausted and parts of the system environment are no longer operable. Page 26 of 98

27 T 4.CM.10 Unauthorised restoration of snapshots T 4.CM.10 Unauthorised restoration of snapshots The status of virtual machines at a certain point in time can be saved by making a snapshots. Thus it is possible to quickly save the configuration and file system of virtual machines. Moreover, the complete current memory contents are saved on the snapshot. Whenever necessary (e.g. prior to installing a patch), cloud administrators can make a snapshot and thus a backup of the system. With this snapshot, the system can be restored at any time, e.g. if a patch does not function properly. If the wrong snapshot is installed, an old version might be installed in the system with old security settings or patches which could cause vulnerabilities in the system. It is also possible that the administrator installs snapshots without having the authorisation. Thus it is possible that the administrator installs a snapshot copy in an external system without authorisation, thus making a complete mirroring of the IT system in an external environment. In this external environment, he can try unnoticed to gain access to the system. Example: - A cloud administrator makes a snapshot of a system where a database with personal data for a HR application is operated. He copies this snapshot unnoticed to an external hard disk and later installs it on his private virtualisation platform. Then he converts the system to a bootable hard disk. By means of a restoration tool he can now start the operating system of this hard disk and reset the local administrator password of the system. Then he can start the system as administrator and assign all necessary database authorisations to himself in order to get access to the database contents. Page 27 of 98

28 T 4.CM.11Incompatibility of cloud administration and administration of cloud elements T 4.CM.11 Incompatibility of cloud administration and administration of cloud elements The cloud infrastructure consists of a number of cloud elements. This does not only include the physical (with CPU, memory and miscellaneous hardware) and virtual servers (with the virtual equivalents of the hardware of the physical server), but also the network (with network coupling elements, cabling) and memory solutions. The areas mentioned have an administration software such as network management tools. These are also referred to as element managers. The cloud administration software usually communicates with the element managers and not directly with the corresponding components (e.g. router). A threat caused by the incorrect communication between cloud administration software and cloud elements occurs if products of different manufacturers (or the same manufacturer) are not compatible with each other and do not support equal logs. The central administration software communicates with the cloud elements via interfaces in order to request the required cloud resources. The improper communication between cloud administration software and cloud elements creates the risk that the cloud elements (such as server, networks, memory) discard the configuration or that communication fails. The feedback regarding the implementation of configurations and utilisation data of cloud elements to the cloud administration software is significant for the orchestration process. If the cloud elements fail to properly report these configurations and utilisation data to the cloud administration software, the cloud management cannot retrace the correct provision of cloud services. Example: - A new version of the management protocol (e.g. SNMP) is used in the communication between cloud administration software and the cloud elements, virtual router and switches. The cloud element manager of the switches, however, does not support the new version. As a consequence, communication fails. Page 28 of 98

29 T 4.CM.12Information unintentionally revealed by cloud cartography T 4.CM.12 Information unintentionally revealed by cloud cartography Inadequate separation, in particular in the cloud-internal network structure, can be identified by attackers via the cloud cartography. The cloud cartography is a scheme for the identification of the physical location of the web servers for cloud applications which are provided by the cloud service provider. The cloud cartography aims at "mapping" the infrastructure of the cloud service provider in order to identify the location where a certain virtual machine is operated. In case of a successful cloud cartography, the attacker gets a detailed picture of the network structure at the cloud service provider from the information gained from accessible cloud elements. This information may be the basis for further attacks. The basic layout of the network can be identified by queries both from outside and inside the cloud: Public IP address areas are identified with Who-is queries. Using tools for the download of web contents will provide you with information on which servers the HTTP service is operating; private IP addresses and host names, if necessary, can be identified via cloud-internal DNS queries. A beneficial result for attackers might be that they are in the position to allocate the geographic areas of availability and the leasable virtual performance levels of the cloud services and the associated virtual machines to the internal IP address ranges. Under certain circumstances, the static allocation of virtual authorities to physical cloud resources might lead to prioritised targets of attack. By means of different processes, attackers can find out whether a virtual authority which they started in the cloud is adjoining an external virtual authority, i.e. operating on the same physical machine. Thus, the external virtual authority might become a possible target of attack. Resources can also be overloaded deliberately when somebody generates an intensive demand for an operating resource provoking an intensive and permanent disturbance of the operating resource, see also T 5.28 Denial of services. Page 29 of 98

30 T 4.20Overloaded information Systems T 4.20 Overloaded information Systems If information or communication systems such as hardware, software, or networks are dimensioned insufficiently, there will come a point when they no longer meet the requirements of the users. Depending on the type of affected systems, this may have numerous adverse effects. Information systems may be overloaded by - existing storage disk space capacities being exceeded, for example when the mailbox is overcrowded during longer absence of the owner, - a system being overused by numerous simultaneous queries overloading the processors, - the applications requiring too much computational power, e.g. if the process output is insufficient for intensive graphics applications, - sending a large number of messages at the same time as a newsletter. As a possible consequence, IT systems or services may be temporarily unavailable or data may be lost. Each storage medium can only store a limited amount of data. When this limit is reached data may be lost or services are no longer available, for example: - users can no longer save data, - incoming s are rejected and no s can be sent, - incoming and possibly outgoing faxes are interrupted, - the logging function is disabled and/or protocol data not yet analysed is overwritten, or - documents can no longer be archived electronically. The capacity of the storage medium may be exhausted suddenly for different reasons, e.g. due to errors in application programs, increased memory requirements of the users, or even due to a targeted attack including the deliberate reduction of the existing disk space in order to prevent logging. Generally, large amounts of data must be saved when archiving electronically. On the one hand, the amounts of data are caused by the large number of documents to be archived for certain files. On the other hand, each newly created version of a document is saved newly under a new version number. Resources can also be overloaded deliberately when somebody generates an intensive demand for an operating resource provoking an intensive and permanent disturbance of the operating resource, see also T 5.28 Denial of services. large amounts of data during archiving Page 30 of 98

31 T 4.22Software vulnerabilities or errors T 4.22 Software vulnerabilities or errors The following applies to every piece of software: the more complex it is, the more frequently programming errors will occur. Software vulnerabilities are understood to refer to unintentional programme errors that are as of yet unknown to the user and constitute a security risk to the IT system. New security loopholes are constantly being found in existing software, including widely used and brand new software. Software errors or vulnerabilities can have a multitude of causes. This includes, for example, communication errors between customers and developers, insufficient training of the programmers, or insufficient testing. Expectations that are too high on the part of the user together with tight release deadlines for standard software can also lead to the manufacturer offering a product before it is ready and which contains errors. If software errors are not detected, the errors resulting from the use of the software can have serious consequences. In the case of common standard software, software vulnerabilities may rapidly result in the world-wide emergence of serious security problems for any type of institution. Examples: - A software error in the RACF security software of the z/os operating system can mean that not only does RACF cease to operate, but that the entire system is now unable to function properly and needs to be restarted. - The strength of the security functions implemented in standard software (such as passwords or encryption algorithms) is often overestimated by users. In many cases, these security functions cannot provide protection against a prolonged attack carried out by someone with the right knowledge. This applies, for example, to the encryption functions integrated into a number of word processing programmes. The Internet provides numerous tools to overcome the encryption available in almost all word processing programmes. - It has been shown that the appearance of a certain word while running the spelling check in a certain word processing program will always cause the program to crash. - Standard software often contains undocumented functions such as Easter eggs or gag screens that the product developers program to leave there own mark. This has the effect of consuming additional IT resources while making it clear, at the same time, that the full functionality of the product cannot be checked down to the last detail in the software test. - Most of the warnings from Computer Emergency Response Teams in the last few years have been related to security-relevant programming errors. These are errors that arise during software development and that make it possible for the software to be misused by attackers. Most of these errors were caused by buffer overflows. These are errors in routines used to read character strings, in which a routine does not check whether the length of the character string entered matches the length of the memory area reserved for it. This makes it possible for attackers to transmit an exceptionally long character string containing additional commands that are then stored past the memory area reserved Page 31 of 98

32 T 4.22Software vulnerabilities or errors for the entry and executed. These commands can be from any type of programme. - A large number of warnings have also been due to denial of service (DoS) attacks, which can cause the entire computer to crash due to errors in individual routines used for processing network data. Page 32 of 98

33 T 5.CM.13Misuse of administrator rights in the cloud management T 5.CM.13 Misuse of administrator rights in the cloud management The cloud management, which is controlled by the cloud administration server, must provide functions and means for the administration of cloud resources. This includes the control of physical and virtual cloud resources in order to make manual or automated configurations. The administration server controls the provisioning and de-provisioning of cloud services, registers the cloud services for cloud clients and is used as the central directory of cloud services. The cloud administration server can highly influence the cloud services which can result in the misuse of cloud management functions. Administration misuse is the deliberate use of administrator privileges (whether legally or illegally acquired) in order to harm the cloud infrastructure or its users. Examples: - The functions of the cloud administration server allow for the allocation of storage areas or virtual machines. It is possible to make unauthorised copies hereof which can be removed from the secured cloud environment without permission. - Via the virtualisation functions, the cloud administration software can write preliminary processor results and contents of the memory to the storage system or to the storage network of the administration server. - The virtual machines for cloud services can be interrupted without authorisation. - The freezing function (creation of so-called snapshots) for freezing virtual machines and cloud services can be misused for bypassing security safeguards. Page 33 of 98

34 T 5.23Malicious software T 5.23 Malicious software Malicious software is software designed specifically with the goal of executing unwanted and usually damaging functions. Common types of malicious software include, among others, viruses, worms, and Trojan horses. Malicious software is usually activated secretly without the knowledge and permission of the user. Malicious software nowadays provides an attacker with extensive communication and control capabilities as well as a number of functions. Specifically, malicious software can be used to obtain passwords, remotely control systems, disable protective software, and spy on data, among other things. The most serious damage that can be caused by such software is the loss or corruption of information or applications. However, the image loss and financial damage that can result from malicious software can also be significant. Examples: - In the past, the W32/Bugbear worm spread itself using two different methods. One method was to search in local networks for computers with shares for which write access was enabled and then copy itself to the share. In addition, it sent itself in an in HTML format to the recipients in the address book of the computers it infected. Due to an error in the HTML routine of certain programs, the malicious software was executed when the message was opened without requiring any action by the recipient. - The W32/Klez worm spread different versions of itself. Infected computers sent the virus to all recipients in the address book of these computers. Once this virus infected a computer, it prevented all further attempts to install the anti-virus software of typical manufacturers by continuously manipulating the operating system. The continuous manipulation of the operating system made disinfecting the infected computer significantly more difficult. Page 34 of 98

35 T 5.28Denial of services T 5.28 Denial of services A denial of service (DoS) attack is intended to prevent users from using functions or devices that are normally available to them. This type of attack is often connected to the use of distributed resources, with the attacker placing such high demands on these resources that other users are prevented from carrying out their work. For example, a shortage of the following resources can be artificially induced: processes, CPU time, disk space, inodes, or directories. This can be caused, for example, - by starting a large number of programs simultaneously, - by simultaneously starting up numerous programs which consume a lot of CPU time, - by allocating all the free inodes on a UNIX system so that no new files can be created, - through uncoordinated allocation of tape units in z/os systems so that applications have to wait for free tape units and online processing is limited, - by deliberately entering incorrect passwords (also using scripts) with the objective of blocking all user IDs on a z/os system, - by sending data packets constructed in a certain way that can cause malfunctions on the recipient's computer due to software vulnerabilities, - by deliberately overloading the network, and - by cutting off network connections. Blocking tape units on the z/os system DoS attacks on z/os user IDs Page 35 of 98

36 T 5.114Misuse of Spanning Tree T Misuse of Spanning Tree The spanning tree protocol is specified in IEEE 802.1d. Spanning Tree is used to prevent the formation of loops within a network comprising several switches. With this variant, redundant network structures are identified and a loop-free structure is formed. This measure reduces the active connection paths on any meshed network structure to a tree structure. In the following illustration it can be seen that a port on the bottom switch has been disabled with the aid of spanning tree. By sending out Bridge Protocol Data Units (BPDUs), a root bridge is identified based on the priority set and MAC address of the switch. In the illustration the switch at the top right is the root bridge. Figure: Spanning Tree Protocol Spanning tree does not provide any authentication on the exchange of BPDUs. This situation can be exploited by attackers in switched networks. If an attacker can send BPDUs from a station connected to a switch, the topology will be recalculated with the aid of the spanning tree algorithm. The convergence for the calculation of the topology change can be 30 seconds with spanning tree. In this way, the availability of the network can be seriously affected by sending BPDUs. Page 36 of 98

37 S 4.CM.01Planning of resources for cloud services S 4.CM.01 Planning of resources for cloud services Initiation responsibility: IT Security Officer, Specialised Department Implementation responsibility: Specialists Responsible A number of general conditions must be taken into account when planning the cloud infrastructure. Besides the questions regarding the virtualisation technology to be used and the products used for this purpose, the suitability of the cloud elements (hardware, software and network connection) and the network structure and storage connection to be implemented must be planned. Furthermore, the compatibility of IT systems and the (administration) software solutions of different providers must be checked when planning the cloud infrastructure. Thus the results of planning must form the selection criteria for hardware and software, as well as for network structure and storage connection. Planning should document the characteristics (dimensioning, throughput) of hardware, software and connections on the basis of which they were selected. This should in particular include contemplations with regard to the compatibility of the components with each other. Selecting the hardware When selecting the hardware for the cloud infrastructure it is important to make sure that it can provide adequate performance for the planned virtual resource layer. In order to meet the scalability and elasticity of the cloud infrastructure, the IT systems and network components used must be suitable and adequately dimensioned and easy to extend, if necessary, in order to provide enough capacities for all virtualised cloud infrastructures, platforms and applications. Planning the network connection It is necessary to plan which technology to use for the connection of the virtual IT systems with the network of the computer centre. This connection may for example be accomplished via virtual switches. Furthermore it is necessary to plan storage networks and their connection (e.g. SAN connection via fibre optic cables). To this end, the safeguard S Planning the use of storage systems must be taken into account. In this context, the network planning for the cloud infrastructure must also take into account the existing segmentation of the network, in which the safeguards S Development of a network concept, S 5.61 Suitable physical segmentation and S 5.62 Suitable logical segmentation must be implemented. Planning for infrastructure services Cloud infrastructure services for all clients must be planned and designed. In their technical environment, cloud services require: - quick and extendible connections to the resources of CPU, memory and storage. - Connections in the storage network for the access to mass storage components. - Connections to infrastructure systems such as DNS, DHCP and directory service servers. - Connections to infrastructure services such as update servers for Page 37 of 98

38 S 4.CM.01Planning of resources for cloud services malware signatures. Planning the use of cloud administration servers When planning the use of cloud administration servers, those particularities must be observed which in particular arise from the requirement that usually several virtual machines are to be operated on the administration server. Therefore it is necessary to determine how much processor performance, main storage and hard disk space is required for the operation of virtual machines. Furthermore it is necessary to specify the network connections required for the virtualisation servers and the virtual machines. A detailed analysis must be made within the framework of the compliance management. In particular, the reliability of the administration server must be adequately designed because the different virtual machines on the cloud administration server include the element managers and the cloud administration software. When planning the cloud infrastructure, the logging and analysis of the log files must also be taken into account (safeguard S 4.CM.14 Logging of events in the cloud infrastructure and S Analysing the log data). The required availability must be maintained within the capacity management. To this end, it must be possible to monitor the utilisation of resources and to provide adequate capacities for storage, CPU and further virtual resources, depending on the requirements. When selecting the administration solution for the cloud management, whether for individual solutions or for complete packages provided by suppliers who also offer element managers and virtualisation solutions, it is necessary to analyse whether the requirements of the cloud service provider and its cloud service users are adequately covered by the complete solution. It must be taken into account that already existing products and IT components of the cloud service provider are compatible with the components of the selected complete solution for the cloud infrastructure. Review questions: - When selecting the hardware for the cloud infrastructure, did you make sure that it has adequate performance capabilities? - Did you take into account the existing segmentation of the network when planning the connection to the network of the computer centre? - Did you take into account all requirements for the connection of the required resources when planning the infrastructure services? - Did you determine how much processor performance, main storage and hard disk space is required for the operation of virtual machines on the administration server? - Did you specify the network connections required for the virtualisation servers and the virtual machines? - Did you specify how the utilisation of resources has to be monitored in order to provide capacities for storage, CPU and further virtual resources tailored to requirements and demand? - Did you analyse whether the requirements of the cloud service provider and the cloud service customer are adequately covered by the administration solution for the cloud management? Page 38 of 98

39 S 4.CM.02Planning of cloud service profiles S 4.CM.02 Planning of cloud service profiles Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrator Due to the high complexity, a detailed planning regarding the provision of cloud services is essential. Therefore it is necessary to analyse the required general conditions already in the conceptual contemplations and prior to project planning. Cloud service profiles are defined in one set of information which describes the cloud resources and their configuration. Cloud resources include CPU, memory, networks or storage systems / storage networks. The cloud service profiles must allow for the error-free automatic reproduction of cloud services. Recording of requirements First of all, the requirements for cloud services must be recorded. For cloud service profiles, as for applications and IT systems, the required components (software, databases, operating systems, networks, infrastructure services such as DNS) as well as their configuration must be planned. Moreover, measurable quality indicators for the cloud services must be determined. Planning of automation How the provision of the cloud service can be automated must be planned. In this connection, security safeguards for multi-tenancy must be taken into account. Depending on the security requirements for multi-tenancy, the cloud service providers must provide different networks, virtualisation hosts or storage systems, if necessary, and prepare the corresponding configurations. For configuration carried out by the cloud service customer: Validation of input It is possible to some extent to define the characteristics of cloud services directly by the input of the cloud service customers and to provide them completely or partly automated. cloud service customers can make their input via administration interfaces or web portals (so-called self-service portals). If it is possible for cloud service customers to configure cloud services in this way, the cloud service providers must plan processes to check this input: Parameters must be pre-defined and thresholds must be specified in the interface logic or in the web portals in order to validate the input of the cloud service customers. Planning of authentication and encryption (access paths) Regardless of the type of cloud service or provision model, the cloud service provider must plan the authentication and access path for the cloud services. This includes the pre-configuration of the Secure Socket Layer (SSL/TLS) for the encryption of the access path. Planning the administration of keys, authentication data, roles and rights The secure storage of key material and authentication data for the controlled access to the cloud service must be designed. In this context, the secure connection to a central identity management system, e.g. via standards such as SAML (Security Assertion Markup Language) for the cloud services must be prepared. The creation of prepared profiles for roles and rights must also be Page 39 of 98

40 S 4.CM.02Planning of cloud service profiles planned in connection with the cloud service profiles and prepared for the reproduction of the cloud service for different clients. Preparing central monitoring For the future monitoring and billing of cloud services, a definition of how to connect central monitoring is necessary and must be saved in the cloud service profiles. Planning a multi-layer security architecture It is necessary to plan settings for a multi-layer security architecture (layered security). Settings for virtual networks, virtual firewalls, VLANs and secure transport channels must be prepared accordingly. Additionally: Taking secure software development and a secure operating environment into account Depending on the configuration of the cloud service profile, security aspects from secure software development must be taken into account. For the development of cloud offers for SaaS, module B 5.21 Web applications must be used. Depending on the type of cloud service, it may be necessary to plan the preparation of encapsulated runtime environments (sandboxing). Review questions: - Are the security requirements for the cloud services recorded and included in the planning of the cloud services? - Are the roles and authorisations for the cloud service profile clearly pre-defined? - Are input validations and thresholds for the provision of cloud services defined? - Are the authentication and encryption of the access path for cloud services planned and do they meet the recognised technical rules? - Has the monitoring of cloud services been taken into account for planning? - Have the settings for network-based multi-tenancy via virtual networks, virtual firewalls, VLANs been taken into account for the planning of the cloud service profiles? Page 40 of 98

41 S 2.CM.03Provision of security policies for cloud service customers S 2.CM.03 Provision of security policies for cloud service customers Initiation responsibility: Specialists Responsible, IT Security Officer Implementation responsibility: Specialists Responsible In cloud computing, the cloud service customer must be involved in the implementation of security safeguards. The scope of involvement may vary depending on the service model (IaaS, PaaS or SaaS see subheadings below). Depending on the type of cloud service and the contractual regulations, the cloud service provider should therefore make the cloud service customer aware of this responsibility and forward security recommendations for the cloud service customer in the form of policies. The policies should include a description of the security safeguards implemented by the cloud service provider. This might enhance mutual trust and increase the transparency of the cloud infrastructure for the cloud service customer. Software as a Service (SaaS) If the cloud service provider offers Software as a Service, there is no need for the cloud service customer to deal with operating system security or the security of the cloud application itself because this is the responsibility of the cloud service provider. Nevertheless, the cloud service customer must be involved in certain security safeguards. Therefore, the cloud service provider should set up a comprehensive submission and approval procedure in the security policies controlling the role and authorisation concept to be established for the cloud application. Basically, the cloud service provider should define standard roles with corresponding authorisations. If cloud service customers need additional roles and authorisations, it will be possible to have the cloud service customer set up these roles. The approval whether a cloud service user may get certain roles or authorisations must be left to the cloud service customer. The task of the cloud service provider on the other hand is to provide a description in the policies which explains the security principles regarding the user and authorisation concept to the cloud service customer. This includes in particular the principle of least privilege. It is recommendable for the cloud service provider to allow and support the connection to an external identity and rights management for his SaaS offers. In the policies for cloud service customers, the cloud service provider should take advantage of the possibility to explain additional security safeguards for higher protection requirements to the customers. The cloud service provider can, for example, describe possible means and ways of encrypting cloud data. Here, he can either offer further cloud services or, for example, refer to means of encryption for cloud service customers. Platform as a Service (PaaS) With the cloud service model Platform as a Service, the cloud service customer has far more possibilities for the implementation of security safeguards for cloud services. Here, the cloud service provider should make security recommendations as to how to secure cloud applications. As the applications are usually web-based, the recommendations should be based on recognised security standards such as OWASP (Open Web Application Security Project) or module B 5.21 Web applications. In particular, central Page 41 of 98

42 S 2.CM.03Provision of security policies for cloud service customers safeguards for the secure programming and configuration of web applications (S Secure configuration of web applications) must be specified. Furthermore, PaaS requires the secure access control and the secure and encrypted authentication of the infrastructure services provided by the cloud service provider (if not provided by the cloud service customer itself). The cloud service customer must also be involved in the design and responsible implementation of the access administration in PaaS. For this purpose, existing IT-Grundschutz safeguards such as S Guidelines for access control can be used as a guide. It is recommended to provide the cloud service customers with the installed safeguards for the protection of PaaS offers (e.g. standards for the hardening of a database) in the form of documentations and implementation examples. Depending on the cloud service and the agreed fields of responsibility, it is also advisable to give security recommendations for the patch and modification management which should be observed by the cloud service customer. In this context it is important to recommend the cloud service customer searching for current patches and updates (if this is included in his field of responsibility) and regularly gain information on possible vulnerabilities of the application and the platform. Furthermore, the security policies should include a security recommendation for testing patches and modifications prior to their commissioning. Infrastructure as a Service (IaaS) For IaaS, the cloud service customer is provided with virtual machines, e.g. via a web interface. In order to secure the virtual machines, it is helpful if the IaaS provider supports his customers with guidelines regarding the hardening of virtual machines. With IaaS, the cloud service customer has the main responsibility for the implementation of security safeguards for the servers and for the secure connection of accesses and to the directory services. However, the cloud service provider should recommend important safeguards as to how to achieve a basic security level for the protection of the server. Here, the cloud service provider should instruct the cloud service customers e.g. on the safeguards included in the corresponding server module of the layer IT systems of the IT-Grundschutz. Cloud service providers should explain how to connect with the virus protection services they offer and recommend a virus protection to be installed by the cloud service customer as a necessary prerequisite for the operation of cloud services. If necessary, cloud service providers may also offer the connection with a virus protection manufacturer as a service in the cloud environment. Moreover, cloud service customers must be informed of any basic hardening measures such as the deactivation of services which are not required. Cloud service providers should also inform cloud service customers regarding standard safeguards for the protection of IT systems, such as host firewalls, host-based intrusion detection systems, etc. Regular integrity tests of major system files can also be forwarded to the cloud service customers as a recommendation. Besides conceptional security recommendations for cloud service customers, Page 42 of 98

43 S 2.CM.03Provision of security policies for cloud service customers technical tools for safe configuration should also be provided for them. Pre-configured profiles for virtual machines, for example, could be offered in this context. These master copies / profiles standardise and simplify configuration. Master copies for a validated configuration already known (with settings for the network, memory and security) can be prepared and provided on several hosts, thus simplifying configuration. Host profile policies may also be used for compliance monitoring. To this end, the cloud service provider should check and approve the profiles or virtual images. The release or provision of profiles and images should include an integrity check for the cloud service customer, e.g. by means of a check sum of the offered file. Information security incident management (for SaaS, PaaS and IaaS) The security policies for cloud service customers must describe the required interfaces for the information security incident management. The reporting paths and contact persons of the cloud service provider must be provided. Moreover, the cloud usage policy for the cloud service customer should include a list of criteria and examples for security-relevant incidents. This list includes: - Name of the person reporting an incident, - the time at which the incident was reported, - responsible cloud service, - description of the incident, - description of the impacts, in particular the data and information which are affected by the incident, - optional: Could any vulnerabilities be identified? - optional: Notes of the cloud service customer on how to eliminate the incident Thus, cloud service customers become more aware of how to effectively support the reporting of the information security incident management of the cloud service provider. - Review questions: - Is there a security policy for cloud service customers and are cloud service customers provided with this policy? - Does the policy include the security safeguards for which the cloud service customer is responsible or which he must implement? - Does the policy include the contact persons and alarm centres for information security issues? - Doe the policy include security-relevant incidents which are subject to reporting? Page 43 of 98

44 S 2.CM.04Contractual arrangements with third-party service providers S 2.CM.04 Contractual arrangements with third-party service providers Initiation responsibility: Top Management Implementation responsibility: Head of Purchasing For the provision of cloud services, cloud service providers are frequently cooperating with software manufacturers or other cloud service providers. If this is the case, the security safeguards of the cloud service provider must be forwarded to these service providers (see module B 1.11 Outsourcing). The following aspects should be arranged in a contract. Secure programming Software manufacturers must be bound to the implementation of standards for secure programming. In order to ensure secure programming, a software development life cycle must be defined and implemented (see also S Development and extension of applications). Moreover, module B 5.21 Web applications includes many safeguards for the secure development of web-based applications. If possible, software manufacturers should sign a contract regarding the compliance with these safeguards. Integration of security functions The cloud service provider is responsible for the security functions in the cloud applications. Software manufacturers must accordingly be informed about the requirements for the security functions. This includes for example cryptographic safeguards (encrypted transmission or storing of data), secure authentication procedures or backup methods. Furthermore, performance requirements as required services with regard to throughput and runtime response must be defined for the third-party service provider. For standardised SaaS solutions, an appropriate requirements catalogue according to safeguard S 2.80 Drawing up a requirements catalogue for standard software must be prepared, and the software manufacturer must be bound by contract to observe it. The requirements include - clearly defined interfaces, - commitment that the application can be virtualised (e.g. the easy and automated reproduction of standard applications in the cloud must be possible), - compatibility with existing versions of interfaces, software or services. It is necessary that third-party manufacturers or cloud service providers make these commitments clearly and bindingly (if possible in written form). Provision of multi-tenancy Clients can for example be separated via the virtualisation of the application infrastructure (i.e. n-fold virtual copy of the application environment of the third-party manufacturer for cloud service customers). Cloud service profiles might in this case be completely provided by third-party manufacturers or other cloud service providers. It must be checked whether the configuration can be automatically extended for further tenants (cloud service customers) and whether this allows for the correct implementation of multi-tenancy on all layers of the cloud IT infrastructure (application, platform, operating system, Page 44 of 98

45 S 2.CM.04Contractual arrangements with third-party service providers virtual server, storage, networks). Patch and change management for a distributed cloud If cloud service providers use the PaaS or IaaS offer of an external cloud service provider (e.g. for a SaaS offer), it is necessary to arrange with the supplying cloud service provider which virtual resources with which patch version and which configuration is required. Here it is essential for the cloud service provider to agree by contract to a controlled process for the patch and change management with clear responsibilities. Working with standardised interfaces (APIs) is recommended. Thus, only the changes made to interfaces must be checked in the change management process. For detailed safeguards, module B 1.14 Patch and change management must be used. Vulnerabilities management at third-party service providers The contract with the third-party service provider must include contact persons for information security for both parties. Furthermore, the areas of responsibility and the interfaces for the information security incident management must be defined. Thus, well-controlled communication can be ensured and controlled processes are used if vulnerabilities occur or are identified in cloud services based on the services of third-party service providers or in the software applied. Places of data processing in case of a distributed cloud In many cases it makes sense or it is even indispensable to define where data is processed by the cloud service. In such cases, the places of data processing must be indicated in the contractual agreements. It must also be regulated in the contract as to how to proceed if places of data processing are changed over time. Liability The liability for damage caused by the software errors of the manufacturer must be stipulated in the contract. Copyright and rights of use In addition to the security requirements, the contract with the third-party service provider must define provisions regarding the rights of software use and regarding copyright, in particular the period of use, further use and ownership. Provisions regarding the termination of services The contract must include provisions as to what to do with the data processed in the application after the termination of the cloud service for a cloud service customer. Data processing If personal data is processed by third-party service providers, it must be checked whether this data is processed as defined by the Federal Data Protection Act. If this is the case, the corresponding legal provisions must be observed (see safeguard S 7.11 Regulation of data processing regarding the processing of personal data). Review questions: - Is there a written contract with all third-party service providers? Page 45 of 98

46 S 2.CM.04Contractual arrangements with third-party service providers - Does the contract include all necessary security-relevant regulations? Page 46 of 98

47 S 2.CM.05Modelling of cloud management S 2.CM.05 Modelling of cloud management Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrator, Head of IT This safeguard defines how to correctly model the cloud management according to the IT-Grundschutz approach. The modules necessary for the IT-Grundschutz are indicated, and a description is provided as to how the different service models (SaaS, PaaS, IaaS) of cloud computing can be illustrated in a security concept. For the definition of the terms for cloud computing, e.g. for the service models, see safeguard S 4.CM.22 Introduction to cloud computing. Module B 5.X Cloud management is aimed at cloud service providers. In order to achieve an adequate overall security for the IT operation of cloud services, it is required to take all cloud services (with their allocated virtual IT systems, networks and further cloud components) systematically into account in the security conception. All IT systems, networks and applications provided by the cloud services, for which the information security management system of the cloud service provider has the operational responsibility on the one hand and which are within their scope of application on the other hand, must be taken into account in accordance with the IT-Grundschutz approach for modelling. Modelling as per IT-Grundschutz approach is the allocation of modules to the existing target objects (IT systems, applications, rooms, etc.). The same rules apply to the modelling for virtual IT systems, networks and applications of the cloud as for physical IT systems which are not provided via cloud computing; the notes provided in chapter 4.4 Selection and adaptation of safeguards of the BSI standard IT-Grundschutz Methodology must be observed. Module B 5.X Cloud management is applied to the cloud administration server for modelling an information system with a cloud management which includes the administrative activities of a cloud service provider. It is thus not modelled for each application, each network or each IT system of the cloud infrastructure. The central safeguards of cloud management are implemented in the cloud administration server, e.g. access protection, the monitoring of cloud resources and the orchestration (provisioning and de-provisioning) of cloud resources. Therefore, module B 5.X Cloud management must be incorporated in the modelling of all service models. The scope of the information system depends on the service model. The area of application of the information system is also the limit of responsibility: At the limit of the information system, the responsibility of the cloud service provider ends and the responsibility of the cloud service customer begins. Modelling of IaaS offers IaaS has the least scope of cloud services compared to PaaS and SaaS (see figure Size of the information system for cloud management based on the service model): In IaaS, the cloud service provider is responsible for the cloud administration server and the virtualisation server. Therefore, the only target objects from layer 5 Applications in IaaS are the Page 47 of 98

48 S 2.CM.05Modelling of cloud management administration and virtualisation software. Thus, the corresponding modules must be selected for these target objects. According to the IT-Grundschutz approach, these are modules for IT systems as servers. For the cloud administration server, modules B Virtualisation and B5.X Cloud management are allocated. For IaaS, the cloud service provider only provides a virtual "shell" over a virtual network. According to IT-Grundschutz, the cloud service provider is responsible for the securing of the network in IaaS, whereas the cloud service customers are responsible for the IT systems of the cloud offer. For the network, the appropriate modules from layer 4 must be modelled (e.g. B 4.1 Heterogeneous networks, B 4.2 Network and system management). Storage space from a storage network is usually allocated to the virtual server; for this purpose, module B Storage systems and storage networks must also be implemented by the cloud service provider. The cloud service customer configures a virtual server from the cloud which is offered via IaaS. Thus, the cloud service customer is also responsible for the implementation of his security safeguards. In order to distinguish the information system of the cloud service provider, this virtual server is located outside the information system of the cloud service provider. The interface for the provision of IaaS cloud services (self-service portal) must be secured by the cloud service provider by means of separation devices (networks, virtual firewalls, routing); if required, module B 5.21 Web applications must be implemented. It is possible to model the IaaS server as IT systems in the security concept of the cloud service provider; however, this is not required because these IT systems are administered by the cloud service customers. Modelling of PaaS offers In PaaS, the cloud service provider is not just responsible for IaaS but also for the provision of a virtual server and a offered platform (e.g. database or web server). Therefore, as with IaaS, the cloud service provider in the PaaS service model must at first model the cloud administration server and the corresponding administration software. There, module B 5.X Cloud management is centrally allocated. Furthermore, the cloud service provider must model an IT system with operating system. Depending on the cloud service, a database or a web server must be modelled for this IT system on the application layer. The PaaS IT system with associated cloud applications must be modelled for each cloud service customer. In this context, tenants with equal platforms, equal applications and equal protection requirements may be combined in one group according to the BSI standards 100-2, section In practice, the cloud services of the PaaS service model are provided via virtual profiles which can be used for several cloud service customers or tenants. For the IT-Grundschutz model it is useful to model this combination in the form of sample servers and make links or duplications for each client. Page 48 of 98

49 S 2.CM.05Modelling of cloud management Modelling of SaaS offers In SaaS, the target objects for the underlying cloud infrastructure must at first be observed as in IaaS and PaaS and allocated to these modules, as described in the chapters above. Compared to PaaS, further applications are modelled on the cloud IT systems in SaaS (e.g. a web service, a web application or a SAP system.). The cloud service provider is responsible for the applications, and most of the security safeguards are implemented by the cloud service provider. (Exceptions, such as the implementation by third-party manufacturers, must be explained in the description for the implementation of safeguards.) Thus the SaaS applications must be modelled in the information system of the cloud service provider. If the corresponding requirements are met, different types of the same SaaS application as well as groups of SaaS applications may be combined in accordance with the BSI standards 100-2, section Reducing complexity by identifying groups of similar assets. Information system for cloud management The figure below shows the specified service models and their areas to be modelled. Figure 1: Size of the information system for cloud management based on the service model Page 49 of 98

50 S 2.CM.05Modelling of cloud management Example: Modelling a cloud service for the PaaS service model In order to show the modelling of cloud management, a practical example is given below. For a better overview, modules of layer 2 Infrastructure are not taken into account in the example. Scenario: Via cloud computing, the cloud service provider provides a platform in the form of an Apache web server and an Oracle database for web-based applications which can be developed by the cloud service customers. The scenario is illustrated in the figure Examples how to model a PaaS cloud service. On the left side, you can see the components of the PaaS cloud service: from the blade server for cloud administration as a basis to the Oracle DB and Apache applications. At the right side of the figure, the applicable modules of the different layer of IT-Grundschutz are allocated to these components. The task in this example is the modelling a virtualisation server as a target object. To this end, the IT-Grundschutz modules B General server and B Virtualisation must be allocated. Module B General server deals with the security aspects which are relevant for servers irrespective of the operating system used. Therefore, this module must always be allocated, irrespective of the whether the virtualisation software is operated with or without an underlying operating system. A cloud administration software and a virtualisation software are operated on the virtualisation server (example: blade server as hardware). There are products for the virtualisation software and the cloud administration software which require an underlying operating system, and others which run on their own without an underlying operating system. If the virtualisation software and the cloud administration software have an underlying operating system, the corresponding module must also be allocated, e.g. B Server under Unix. With the virtualisation server as a central IT system, module B 5.X Cloud management is linked on layer 5 as an application module for modelling. Furthermore, this server can provide further applications for the cloud administration, e.g. a web service to allow for access to the cloud administration software. In this case, modules B 5.4 Web server and B 5.21 Web applications must be modelled. Using the cloud administration software, a virtual LAN (VLAN) is provided for each PaaS cloud service customer to allow for the access to their cloud services. For modelling, a virtual IT system (in the example with a Windows 2003 server) must be modelled as a server. For the virtual server, modules B General server and B Windows 2003 Server are used. Then the applicable network modules B 4.2 Network and system management and B 4.1 Heterogeneous networks must be modelled at a VLAN-XY network. The VLAN-XY is linked with a virtual IT system. An Oracle database is modelled on layer 5 Applications with module B 5.7 Database and allocated to the virtual IT system. Moreover, an Apache web Page 50 of 98

51 S 2.CM.05Modelling of cloud management server is modelled with module B 5.4 Web server and also allocated to the virtual IT system. The modelled server with applications and the corresponding VLAN can now be used as a "profile" for the use of the PaaS by different cloud service customers as tenants. (Logic groups may now be created, whereby the provisions for correct grouping according to BSI standard IT-Grundschutz Methodology section are taken into account) It must be possible for the cloud service provider to find out the number of PaaS cloud services provided (i.e. the number of active "copies" of this "profile") in the cloud administration software. Figure 2: Example of the modelling of a PaaS cloud service Page 51 of 98

52 S 4.CM.06Selection of cloud components S 4.CM.06 Selection of cloud components Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrators Depending on the selected provision model of cloud offers (IaaS, PaaS, SaaS), there are different requirements for hardware and virtualisation solutions (see S 4.CM.1 Planning of resources for cloud services). Individual requirements for the underlying hardware architecture or the equipment of the administration server for the cloud infrastructure with hardware components and their connection to the storage networks or mass storage devices result hereof. These requirements must be observed for the procurement of server systems if they are used as cloud administration servers. Requirements for virtualisation servers which are mostly a major part of the cloud solution are defined in safeguard S Selection of suitable hardware for virtualisation environments. The following aspects should be observed when selecting cloud components: - When selecting the hardware for the cloud infrastructure, you should bear in mind the high scalability of cloud services; therefore it is necessary to select extendible modular hardware solutions. It must also be possible to link the hardware with new and extended hardware blocks. - The hardware and software for cloud services must be designed so that the requirements placed on the availability of the server and the integrity of the cloud service customer data can be met. Realistic assumptions must be made for the amounts of data. - A concept must be made for the connection to existing storage networks or storage networks to be procured and the interface for the administration of storage networks or storage devices, and the required components must be procured. In many cases, the best solution is a selection of products and solutions of one manufacturer which are compatible with each other. For the connection and selection of storage systems and storage networks, safeguard S Selection of a suitable storage system must be implemented. - The administration and management of the cloud infrastructure must meet the requirements for secure access (see safeguard S 5.CM.09 Protection of communication to cloud access). Thus, the selected software products for the cloud administration must take into account logs with encryption which is secure enough for the requirements of the cloud service customers (see safeguard S Selection of a suitable cryptographic procedure) and with a high degree of authentication. - An administration solution for cloud components must be developed which allows for the necessary prompt distribution of resources; therefore, virtualisation tools should be used. Moreover, the administration server must have physical connections with all networks for the cloud infrastructure. - The solution to be selected for cloud administration must allow for the implementation of multi-tenant capabilities both in administration and for provisioning and de-provisioning. - The software and virtualisation solutions must allow for the Page 52 of 98

53 S 4.CM.06Selection of cloud components implementation of a role and rights concept (multi-tenant capabilities). It must be possible to restrict the authorisations of the cloud administrators and, if necessary, to allow for a client-related separation of roles between administrators on administrator level. - For SaaS: Many cloud service customers expect the interoperability and portability of cloud data. This can be achieved by standardised and disclosed interfaces and formats. Accordingly, the cloud applications which are developed or selected should provide standardised interfaces and allow for exports in popular file formats (API, logs). Thus, the cloud service customer does not depend on any platform. - The communication between administration server and virtual and physical resource control layers is subject to compatibility requirements. Therefore, when selecting the hardware and software components (in particular the network management, virtualisation server, storage system control), you must make sure that the cloud element manager and the orchestration server can correctly communicate with each other such that the required availability of the cloud services can be ensured. Review questions: - Is an extendible modular hardware solution selected for the cloud infrastructure in order to allow for the required scaling of the cloud services? - Are the storage networks and the interfaces to the administration of the storage network planned such that they can be connected to existing components or to components to be procured? - Do the logs of the selected software product for the cloud administration offer an encryption which is secure enough and a high degree of authentication for administrative access? - Does the applied administration solution allow for the prompt distribution of resources by the cloud components? - Does the applied administration solution allow for the implementation of multi-tenant capabilities for the cloud components both in administration and for provisioning and de-provisioning? - Does the applied software and virtualisation solution allow for the implementation of a role and rights concept? - For SaaS: Are standardised and disclosed interfaces and formats used such that the expectations of cloud service customers with regard to interoperability and portability of cloud data are met? Page 53 of 98

54 S 4.CM.07Virtual security gateways (firewalls) in clouds S 4.CM.07 Virtual security gateways (firewalls) in clouds Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrator, IT Security Officer In a cloud infrastructure, cloud services are operated which can be accessed by the cloud service users. Thus, a system including various cloud services is created for each cloud service customer which they can use. This system is operated on one or several virtual machines. It is hereinafter referred to as customer system. For the protection of the cloud solutions, security gateways (firewalls) should be used for each virtual machine in order to secure the communication between the customer systems and the administration servers. If technically possible, the clients should be separated from each other and isolated from one another. There are different options of implementation, e.g. as installation of a virtual application on the host, or as a Kernel module of the central component of the virtualisation server (hypervisor) for virtual IT systems. The security gateways (firewalls) control the IP services which can be used between user system, administration system and external system. Firewalls must ensure the segmentation of services by creating trust zones which are to be set as restrictively as possible. Customer systems should not have any access to the administration servers. The following principle is applicable in this case: Everything which is not explicitly allowed is forbidden. The applied firewall solution must ensure, on the basis of firewall directives, that the network traffic between the virtual machines is controlled and monitored, in particular if they move to another virtual host or if virtual profiles are copied for new cloud clients. After initial configuration, the filter rules of the firewalls should be tested as to whether they allow permitted incidents and prevent unauthorised incidents. The communication of the virtual IT systems with other virtual or physical IT systems must be planned in detail. Existing security policies must be observed. It is not permitted to bypass security gateways or monitoring systems in the network with means of virtualisation. This especially applies to virtualisation products with a network traffic between virtualised IT systems which is not necessarily implemented via physical networks. If virtual IT systems must be connected with several networks, it is necessary to make sure that the establishment of any undesired network connection via these networks is prevented. In particular the connections between the administration networks of the virtualisation servers and the networks of the productive virtual IT systems must be prevented. Otherwise you risk compromising the virtualisation servers. This must be prevented either by physical or logical separation (e.g. via VLANs). Review questions: - Are the administration networks of the virtualisation servers separated from the productive networks with customer systems by the firewall policies? - Are the systems of the different cloud clients separated from each other Page 54 of 98

55 S 4.CM.07Virtual security gateways (firewalls) in clouds by firewall policies? Page 55 of 98

56 S 5.CM.08Securing the communication to the cloud access S 5.CM.08 Securing the communication to the cloud access Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrator Cloud service providers provide public interfaces for the interaction with the cloud service users. This is usually implemented via web interfaces. Via these interfaces, cloud service users centrally access the cloud services provided by the cloud service provider. Secure interfaces and protocols must be used for this purpose which allow for the encrypted communication between cloud service provider and cloud service user. Encryption and authentication In order to protect communication, secure protocols with adequate encryption and authentication meeting the recognised technical rules must be used. Secure protocols can be determined with safeguard S Selection of suitable cryptographic procedure. The technical policy TR Cryptographic procedures: Recommendations and key lengths of BSI is also very helpful. General principle: HTTPS instead of HTTP A basic example is that all web-based cloud offers must be secured via HTTPS. To this end, safeguard S 5.66 Use of TLS/SSL of module B 5.21 Web applications must be implemented. For web-based access, protected communication is usually implemented by client server communication via HTTPS where the client can check the server certificate. For cloud services with security-relevant data, certificates with trusted certification authorities must be used. For non security-relevant data, self-created certificates are sufficient. The latter applies for example to private cloud services which are uncritical with regard to confidentiality. Service-specific protection or protection of the network Protected communication is not only requested for HTTPS but also for all cloud services provided by cloud computing. The use of a directory service via cloud services, for example, would be possible, with applied service-specific protocols (here for example LDAP). If LDAP is used, the encrypted LDAP variant must be used for all cloud services. Here, the underlying network connections are protected by Transport Layer Security (TLS, frequently also referred to as SSL, its former designation). Secure handling of passwords Some basic security safeguards must be observed when using passwords. The implementation of an adequate password policy must be ensured. Details are provided in policy S 2.11 Provisions governing the use of passwords. The passwords for web applications must be provided with so-called password salts which are encrypted as random prefix together with the passwords. This function is to prevent the easy pre-calculation of passwords. Passwords must not be provided in the client cache; this must be prevented by the server or the user. Moreover, the auto-complete function for passwords Page 56 of 98

57 S 5.CM.08Securing the communication to the cloud access must be deactivated. Session management In order to protect session IDs in the web application, the contents of safeguard S Secure configuration of web applications must be observed. Further requirements are provided in safeguard S Session management for web applications. Review questions: - Does the communication to cloud access use HTTPS (instead of HTTP) or is it protected by TLS / SSL? - If no HTTP is used: Is there any other adequate protection by service-specific protocols? - In case of communication via public networks: Are certificates for HTTPS (or other encryption methods) obtained from an official certification authority (CA)? Page 57 of 98

58 S 4.CM.09Encrypted storage of cloud service customer data S 4.CM.09 Encrypted storage of cloud service customer data Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrator In addition to the encrypted transmission via public networks, the encrypted storage of cloud service customer data may be necessary to avoid administrators or other employees of the cloud service provider being able to access stored information. One option for the encryption of cloud databases is that the cloud service provider provides and uses the means of encryption, i.e. procedure and key are kept at the cloud service provider. As an alternative option, the cloud service customer has the key and the cloud service provider provides the encryption. The latter should be preferred if the applied cloud service model provides suitable corresponding technical capabilities. For the encryption of cloud databases, a suitable encryption algorithm must be used in a way that any data loss is avoided by the system in case of malfunctions (mains failure, cancellation of the process). A suitable encryption algorithm should be selected on the basis of safeguard S Selection of a suitable cryptographic procedure. The implementation of encrypted storage very much depends on the service model (PaaS, IaaS, SaaS) and the provided architecture: Example: PaaS / database Encryption can be made on database level, e.g. via field-based encryption and decryption (see S 4.72 Database encryption). For database encryption, it is important to take into account the export and import functions which might possibly transfer non-encrypted data. Some database management systems offer an additional authorisation environment with the help of which it is possible to deny reading access for the database administrators on the field level of the database e.g. by blocking the Select command for the database administrator. In this case, database administrators can insert or delete tables and make backup operations, however they cannot see the content of the tables. This kind of "data suppression" requires an additional authorisation concept and a two-person rule for those who assign authorisations for database administrators. The information of the cloud service customer in the database can thus be efficiently protected against unauthorised reading by the administrators. Example: IaaS / hard disk encryption In IaaS, the virtual hard disk might be encrypted. Depending on the applied solution for hard disk encryption, the system integrity can be checked during the boot process. In this case, only the cloud service customer can decrypt the hard disk. Decryption is usually carried out automatically after the input of a password or a PIN any time the cloud service user wants to access the data of the encrypted database. Page 58 of 98

59 S 4.CM.09Encrypted storage of cloud service customer data In this case, the administrator of the cloud service provider cannot read the user data. For hard disk encryption, you must make sure that the backup method supports the encryption. If data backup is made without encryption, information may possibly be uncovered. Example: IaaS or PaaS / Provision of tools for encryption In this scenario, the cloud service provider provides the cloud service customer with software for separate encryption, e.g. container solutions which can be used by the cloud service customer with a password for the encryption of the data stored in the container. In this case, the cloud service customer is responsible for the key management and the encrypted storage. Example: SaaS / Encryption using the application logic The cloud service provider, here also software supplier, incorporates a proprietary encryption in the cloud application (SaaS) which stores the data in encrypted form at the user. In this case, the cloud service provider / software supplier is responsible for the use and administration of the encryption. Review questions: - Is confidential cloud service customer data encrypted in a way that the cloud administrator does not have any access to the information? Page 59 of 98

60 S 4.CM.10Multi-factor authentication for cloud service user access S 4.CM.10 Multi-factor authentication for cloud service user access Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrators The controlled access to the resources and data of different cloud service customers is a major aspect for the implementation of client-capable (multi-tenant) cloud solutions with a heterogeneous customer structure. To this end, different authentication procedures can be used. Multi-factor authentication is a safe solution for this purpose. At least two factors are required for successful authentication. A combination of knowledge (password, PIN, or the like) and possession (chip card, USB stick, or the like) is often used in this context. The two-factor authentication can, for example, be implemented by the hardware-based authentication with chip cards or USB sticks or with one-time passwords which are generated by the hardware components. The following points must be observed for the implementation of cloud solutions with regard to authentication: - The access to all IT systems or cloud services must be secured in any case by the authentication of the accessing users or IT systems, even if it is only with a password. - For security-critical fields of application, an effective authentication, i.e. at least a two-factor authentication, should be used if the applied cloud service is directly accessed via the internet. - Multi-factor authentication is recommended in particular for the registration of privileged cloud service users for the administration of cloud services. Moreover, the cloud service customer must decide based on risks whether this secure authentication procedure shall be expanded to further users of its cloud services. - The installation of a multi-factor authentication for self-service portals is recommended. There, the cloud service users can administer their cloud services and directly transfer the changed cloud requirements and thus the associated cloud resources via the application to the automated orchestration of the cloud service provider who can bill it accordingly. Since most of the portals are provided as web applications, please refer to module B 5.21 Web applications for security recommendations regarding further protection for the self-service portal. - There are also scenarios in which the user undergoes multi-factor authentication even before he registers for the cloud services. This could for example be the case for the user registration at the customer network of the cloud service customer or for the establishment of a VPN connection from the customer network with cloud. In this case, there is no need for another multi-factor authentication for the cloud registration. Review questions: - Is multi-factor authentication used for security-critical fields of application (e.g. administration, self-service portal, or protection requirements higher than "normal") if the access to the applied cloud service is directly accessed via the internet? Page 60 of 98

61 S 4.CM.10Multi-factor authentication for cloud service user access - Is multi-factor authentication used for the registration of privileged cloud service users? Page 61 of 98

62 S 3.CM.11Training for the administrators of cloud infrastructures S 3.CM.11 Training for the administrators of cloud infrastructures Initiation responsibility: Top Management, IT Security Officer Implementation responsibility: IT Security Officer, Head of IT Cloud administrators must get a training for their tasks. The training should take place before they start their work and must be repeated on a regular basis due to the short innovation and update cycle for cloud computing. The cloud administrators must learn during the training how to handle their tasks. If administration is classified in specific roles, and if the administrator is responsible for certain special roles, this must be taken into account during the training. The main task of cloud administrators is the administration of the various components of the cloud infrastructure on the basis of cloud administration solutions. This means that cloud administrators in productive operation set up and monitor the automated allocation of virtual resources and incorporate additional physical resources in the cloud, if necessary. Thus, the trainings must convey the knowledge of how to administer the cloud infrastructure in an effective and efficient way. The best way to achieve this is with manufacturer-specific training. The training should not only cover the pure know-how of the applied cloud administration solutions. The cloud administrators must also be trained in the processes and procedures of the cloud service provider. The following central aspects of cloud administration must be covered in the training: - Knowledge of the relevant applied techniques, components and functions. - The various technical levels (applications, IT systems, networks and storage systems) of the cloud infrastructure. - The handling of different cloud clients shared configuration settings on the one hand and required separation on the other hand. - The provisioning and de-provisioning of cloud resources. Further aspects of cloud administration should be covered in the training: - Automation of processes or procedures, in particular with regard to provisioning and de-provisioning. - Creation, administration and duplication of cloud service profiles. - Interfaces for virtualisation, network management and storage systems. - Identification of the impacts of configuration changes, prevention of errors. - Troubleshooting in the cloud infrastructure. - Optimal use of security features and technical functions. Review questions: - What is done to ensure that the cloud administrators have a perfect knowledge of how to use the cloud administration tools? - Are the cloud administrators trained in the defined administration processes of the cloud infrastructure? Page 62 of 98

63 S 5.71Intrusion detection and intrusion response systems S 5.71 Intrusion detection and intrusion response systems Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrator One of the major tasks of firewall administrators is to analyse all protocol data in order to be able to promptly detect attacks. The abundance of data and the multitude and complexity of different attacks create a considerable amount of work. Intrusion detection (ID) and intrusion response (IR) systems may be of help in this case. The aim of ID systems must be to support average administrators insofar that they are in the position to detect attacks in a large number of protocol data even without any profound knowledge of internet security. IR systems, on the other hand, allow for the automatic introduction of countermeasures once an attack has been identified. These programs ideally have as much information as a good administrator and are thus in the position not only to detect an attack in any protocol data but also to appraise how high the risk is and to start necessary countermeasures. However this is an area which still has to be intensively researched, meaning that major improvements of the existing programs are possible at any time. Intrusion detection systems can be classified in two major categories: Signature analysis and anomaly detection. Signature analysis is based on the assumption that many attacks can be detected on the basis of a certain sequence of protocol data. One example is the so-called port scanning. In preparation for an attack, the services are determined which can be accessed on the attacked processor, i.e. to which TCP ports a connection is possible. To this end, a connection establishment package is sent by means of a program to all TCP ports, one after the other. Wherever a connection is established, a service is installed which can be attacked. The corresponding signature, i.e. the identifying feature, of this attack is simple: Connection establishment packages which are sent to all TCP ports, one after the other. There are, however, also problems involved with this kind of attack detection: In which order must the ports be addressed and in which time intervals, so that an attack can be distinguished from normal operation? Current port scanning programs do not address port 1, port 2 up to port n one after the other, instead they randomly address the ports. Moreover it is not possible to send packages directly one after the other, but in random intervals (e.g. 1 s, 100 ms, 333 ms, 5 s...). This is the reason why the creation of a signature is difficult. A subtle variant of port scanning is to send each package from a different source address. In combination with the initiation of packages at staggered intervals, it is presently highly probable that such an attack would go undetected. The assumption for the detection of anomalies is that the normal behaviour of users or processors can be captured statistically, and any deviation is evaluated as an attack. An example is the period of time which a user is normally logged onto their processor. For example, if they almost always work from Monday to Friday from 8 am until 5 pm with a deviation of max. 2 hours, any activity Page 63 of 98

64 S 5.71Intrusion detection and intrusion response systems on Saturday or at midnight can be deemed an attack. The problem with the detection of anomalies is the definition of normal behaviour. Although it is possible to gain some information on the basis of thresholds or probability calculations. The question remains as to whether it makes sense to evaluate any activities of user A on Monday at 7.10 pm as an attack. Moreover, the normal behaviour of the user usually changes and adaptations must be made. But who will tell the ID system that this changed behaviour is normal and does not need to be evaluated as an attack? Furthermore, the deviation of the ID systems with regard to the type of data collection would be useful. This can either be done by means of a dedicated sniffer anywhere in the network (network-based ID system), or be a part of the normal protocol functions on one of the connected processors (host-based ID system). Both have advantages and disadvantages. Although the network-based systems are more easily in the position to detect a complete attack affecting different processors at the same time, it is much more difficult to detect complex attacks (e.g. via further intermediate stations) on a processor. Moreover, network-based systems cannot analyse encrypted data. On the other hand it might be necessary for host-based ID systems to make comprehensive changes regarding the protocol functions of the processor before they can be used. Since the data protection regulations or human resources agreements must be observed even for the automated evaluation of protocol information, it might be necessary to store this data under a pseudonym. The following aspects should be observed before coupling ID system, IR system and the firewall: - Is it possible to initiate a targeted attack on the firewall which is evaluated by the ID system as a real attack by mistake? The consequential blocking of certain services by the IR system via the firewall may have considerable consequences on availability. - The interaction between ID system, IR system and firewall must be documented in a sufficiently transparent way. Otherwise it is not possible to evaluate at any time by whom the firewall is administered: by the IR system or by the administration staff. In case of doubt, the decisions of the administration staff should have priority. In order to prevent the ID system from being attacked, it should be as invisible in the network as possible. The simplest safeguard is the assignment of an IP address which is not routed in the internet. Another recommendation is the deactivation of the ARP protocol for each interface to avoid any reaction to ARP and IP packages. Review questions: - Intrusion detection and intrusion defence by means of intrusion detection and intrusion response systems? Page 64 of 98

65 S 2.CM.12Use of a highly-available firewall S 2.CM.12 Use of a highly-available firewall Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrator, IT Security Officer The reliability of the cloud infrastructure must be ensured. In case of high or very high requirements for the availability of security gateways, redundancies should be installed for physical resources and for the network connection or the linking of the cloud infrastructure components. The security gateway should always be the sole interface between the external network and the network to be protected. Thus the security gateway is a potential bottleneck with regard to data flow on the one hand, and a possible security vulnerability for the whole network traffic of organisations on the other hand. Basically it is possible to design the security gateways to the cloud infrastructure just like the classic security devices of company networks, i.e. by means of separate physical hardware which is combined in a cluster. Optionally, cloud service providers can also use their virtual IT infrastructure and operate the security gateway as a virtual machine which is encapsulated in the network (e.g. separated by VLAN). However, a risk analysis must be made to this end. The major components of a security gateway should be designed with redundancies. This applies in particular to those components which are used for the transmission of information. This category usually includes router, package filter, application level gateway and VPN components, if available. For other components (e.g. protection against malware [virus scanner] or intrusion detection system), the importance of the security of the network to be protected must be evaluated for each individual case. There are different ways to increase the availability of the components of a security gateway. Hot standby systems or solutions with systems combined in a cluster may allow for the dynamic parallel operation of firewalls. This may be achieved, for example, with a High Availability solution (HA solution). The availability of components of the security gateways is monitored, and in case of failure, replacement systems automatically take over the operation. In this context, the permanent monitoring of the HA components is as important as an operable failover in case of need. Moreover, adequate load balancing must be ensured which avoids the overload of individual systems or feed lines when transmitting data packages. Further requirements for high availability solutions and high availability security gateways and information on which one to use and implement are provided in safeguard S Security gateways and high availability. Review questions: - Are the firewall systems for the cloud services designed with redundancies? - Are the failover functions regularly checked? Page 65 of 98

66 S 4.CM.13Central protection against malware in the cloud infrastructure S 4.CM.13 Central protection against malware in the cloud infrastructure Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrators Due to the high concentration of data and applications in the cloud infrastructure, a central component for the protection from malware must be run for the additional local protection from malware. This central protection against malware ( anti-virus ) must be set up at the central access points to the network of the cloud service provider. An application level gateway (ALG) should be used to this end. Safeguard S Integration of virus scanners in a security gateway must be used and implemented for this purpose. It is useful for the central protection of malware to select a protection program of a supplier other than for the local protection in order to maximise the detection rate of malware. Review questions: - Is a central protection against malware used in addition to the local components, meeting the recognised technical rules? Page 66 of 98

67 S 4.CM.14Logging and monitoring of events in the cloud infrastructure S 4.CM.14 Logging and monitoring of events in the cloud infrastructure Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrators Adequate logging must be ensured in the cloud infrastructure in order to be able to detect technical problems and potential attacks and to react accordingly. Since the cloud infrastructure is highly integrated and has a central cloud management, it is necessary to introduce central logs and implement module B 5.22 Logging. The primary aim of monitoring is to control operation, and the collected data is used for the reporting to the cloud service customer (see S 2.CM.20 Reporting and communication to the cloud service customers). The following aspects must be taken into account for adequate logging and monitoring: - Within the framework of cloud management, the applied cloud resources must be monitored in order to regularly check the resources defined in planning and compare them with the current use and demand. - Depending on the service model and service level agreement, the cloud services must be adequately monitored with regard to availability and other measurable parameters which are part of the agreement. - Public and private cloud offers must be monitored around the clock (24/7), and staff must be provided who can react promptly to attacks or security incidents. Reaction times are defined in the service level agreement. The manual interaction as a reaction to incidents during office hours may be adequate for private cloud offers if this is agreed in the service level agreements of the cloud services. - The cloud service provider is responsible for the logging and monitoring capabilities which are differently designed for each service model. For example, if Infrastructure as a Service is offered, the responsibility for logging is on the platform and application level of the cloud service customers. In this case, the cloud service provider may offer the connection to his monitoring systems as an additional service for the cloud service customers. In this case, the cloud service provider must adequately implement the safeguards for log evaluation (see S Analysing the logged data). - Logging must always be set up technically on all existing levels of the cloud infrastructure (applications/services, platforms, infrastructure). For the appropriate set-up on all levels, the logging safeguards of the modules to be modelled provided in the IT-Grundschutz catalogues must be used (e.g. on IT system level safeguard S 5.9 Logging on the server). - If the cloud service provider or the cloud service customer have requirements with regard to computer forensics or legal requirements with regard to revision-proof logging, the cloud service provider must install mechanisms for the log files which secure integrity. In order to prove integrity, for example, log files can be provided with a digital signature or with checksums. In any case, logging access rights may only be granted very restrictively. - The access rights to log files must be evaluated on a regular basis (e.g. twice a year). Page 67 of 98

68 S 4.CM.14Logging and monitoring of events in the cloud infrastructure - For administrative traceability, all critical administrative activities must be logged (e.g. starting services and changing log files). Thus the cloud service provider can provide traceable proof for his customer of who made which changes to the provided services and data, if any, at what time. - The following aspects must at least be logged from the point of view of the cloud management and must be taken into account for the implementation of safeguard S Planning the logging procedure: - Network load and connection interruptions, - connection times (cloud management process SLA), - login and logout of the cloud service users, in particular incorrect login attempts, - changes to roles and authorisations, - critical transactions of the cloud administrators and the privileged cloud service users, if any (the logging of privileged users on application level in SaaS is administered by the cloud service provider, and in IaaS or PaaS systems by the cloud service customers), - recording of changes to the configuration of cloud service profiles in order to simplify error analyses, - utilisation of cloud resources (CPU, network, storage), - attempted attacks, - attempts of unauthorised access or manipulation. - Client separation should also be made for the access to the log files in order to make them available for the cloud service customers without infringing the confidentiality of the log data of other clients and in order to use them for court hearings. Review questions: - Are incidents logged in the cloud infrastructure as required? - Are actions carried out by users (non-privileged and privileged) logged as required? - Do the log records contain the required information? - Is logging carried out on all required levels? - Is the access to log data capable of multi-tenancy? - Is the effective evaluation of logs possible? - Is the access to records restricted to authorised persons? Page 68 of 98

69 S 4.CM.15Patch management for cloud components S 4.CM.15 Patch management for cloud components Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Change Manager, Administrator All cloud components must be integrated in the patch and change management (see module B 1.14 Patch and change management). The responsibilities according to safeguard S Specification of responsibilities for patch and change management must be taken into account for the patch management and for the accomplishment of cloud component patching. With the increasing complexity of cloud infrastructures it is usual that the employees of different divisions of the cloud service provider are assigned with different responsibilities with regard to patching. For example, different persons are responsible for - networks (infrastructure components, router, switches, etc.) - operating systems - virtualisation components - applications - security components (e.g. security gateway, protection against malware, intrusion detection). It is necessary to obtain information on new patches from the software suppliers and publishers of patches on a regular basis (see also S 2.35 Obtaining information on security weaknesses of the system). The patch management forms the basic process for the control of a consistent and adequate security level by providing current patch versions. Detailed specifications on how to patch applications is provided in safeguard S Prompt installation of security-relevant patches and updates. The patch management in the cloud includes different subtasks (detailed information on the terms in the list below is provided in safeguard S 4.CM.22 Introduction to cloud management): - Patching cloud services (PaaS or SaaS) - Patching of underlying cloud infrastructure (IaaS, PaaS and SaaS) including access components such as the self-service portal) - Patching of the cloud administration server and the cloud administration software - Patching of cloud resources and element managers To observe safeguard S Handling change requests when patching cloud services is recommended. The following must be observed for cloud management with regard to the aspects "Evaluation of impacts" and the schedule ("planned date for the implementation of changes"): - The patch and change management should be settled in the contracts / service level agreements (SLA) with the cloud service customers. - These agreements with regard to patch and change management may include the regulation of standard changes (see safeguard S 3.66 Basic terminology of patch and change management). - During patching, cloud services might be available only with restricted functions or reduced performance or not at all, which has effects on the functionality of the cloud service customers. Page 69 of 98

70 S 4.CM.15Patch management for cloud components - Even in case of best possible preparation, unforeseeable impacts are possible which might impair the function or availability of cloud services after patching. It might even be necessary to undo changes. - Due to these possible impacts, all cloud service customers involved should be informed about pending patches, corresponding schedules and possible impacts. - The duty to inform about pending patches and according agreements with the cloud service customer must be contractually defined (service level agreement, SLA). The areas of influence and thus the responsibility of the cloud service provider and the cloud service customer are defined by the various service models. In case of IaaS, the patch capabilities for the cloud service provider are restricted. In this case, the cloud service customer is responsible for the patch and change management on operating system level, platform level and application level. These areas of responsibility should be clearly defined in the service level agreement (SLA). The continuous virtualisation for cloud computing is beneficial for the patch and change management. The load balancing and flexibility of virtual resources allows for new strategies for patching. For example, the operating system provided in a SaaS offer can be patched without interrupting the availability of the cloud service. Furthermore, the cloud administration solution allows for the use of patch strategies with almost completely automated change processes. The automation of the roll-out of current patch versions, e.g via cloud service profiles, is generally recommended. However, it must be ensured that the configurations of the cloud resources are not impaired by new patches. All changes must be planned, tested, approved and documented according to safeguard S Change management or safeguard S Prompt installation of security-relevant patches and updates. If complete tests are not possible on special test systems, at least the configurations must be checked for possible impacts of patches. When rolling out an application for a new client, the software used for this client must be updated to the current patch version before allowing external access to the application. In practice, the patch version of the operating systems and applications offered in the cloud should be administered via the so-called update manager of the cloud or virtualisation product. To this end, updates must be configured which are to be made for the operating systems and applications on the virtualisation hosts and the virtual machines. Review questions: - Are persons responsible for cloud service patches appointed? - When rolling out new clients, are all software versions updated to the current patch version before external access to the application is granted? - Is the responsibility for patching cloud systems agreed in the SLA? Page 70 of 98

71 S 4.CM.16Consistent separation of clients from the cloud services S 4.CM.16 Consistent separation of clients from the cloud services Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrators Multi-tenancy (client separation) must be installed in order to prevent the unauthorised access of one client (cloud service customer) to the information of other clients (cloud service customers). Furthermore, the access of any cloud service customer to the resources of other cloud service customers, e.g. virtual machines, networks or cloud storage, must be prevented. General principles for multi-tenancy Multi-tenancy is technically implemented on different components of the cloud infrastructure. The IT-Grundschutz provides modules for each individual component which describe the safeguards to be taken for client separation (depending on the component, see in particular module B Routers and switches, B Storage systems and storage networks, B Security gateway (firewall) and B 4.1 Heterogeneous networks). The cloud management ensures the consistent multi-tenancy on all relevant levels of the cloud services and the cloud infrastructure. The multi-tenancy at individual components of the cloud infrastructure is installed by the administrators of these components. The request for consistent multi-tenancy for cloud services requires that the persons responsible for the cloud management (e.g. the cloud administrator) must check the multi-tenancy. The cloud service provider must check whether the safeguards for multi-tenancy have been implemented and are effective both in the application and in the server virtualisation, in the network and in the network storage. The cloud management forms the framework for all involved IT-Grundschutz levels, whereas the specific technical or organisational implementation remains with the other modules to be modelled for cloud computing (see S 2.CM.05 Modelling of Cloud Management). The technical isolation of cloud service customers and their data can be achieved by firewalls, access lists, tagging, VLANs, virtualisation, safeguards taken in the storage network (e.g. LUN masking) and physical separation. Checking client separation In order to check the multi-tenancy in each cloud component, the cloud service provider must set up checks. He must retrace the responses of the cloud components for the implementation of the safeguards for client separation. The implementation of safeguards for multi-tenancy can be retraced by: - test and approval procedures of the cloud service profiles, - the evaluation of log files of the cloud administration, - the manual check of configuration files at the cloud elements, or - carrying out penetration checks for the validation of multi-tenancy. Client separation on application level Applications and cloud data can be securely isolated in separate areas (sandboxes), virtually separated storage areas or through the marking of data by tagging. The implementation responsibility of these safeguards does not remain with the cloud management but with the responsible persons in the Page 71 of 98

72 S 4.CM.16Consistent separation of clients from the cloud services application development division which are to implement the multi-tenancy specified by the cloud service provider. For web-based cloud services, the recommendation of module B 5.21 Web applications must be implemented. For PaaS: Client separation on platform level In case of PaaS offers, databases can be offered as cloud services. In this case, the cloud service provider must install a multi-tenancy in the database. This multi-tenancy can be accomplished in different ways: - with a separate database for each cloud service customer (e.g. a virtualised database for each client) - by separating client data using tagging methods (i.e. labelling the database with additional information), or - by creating separated tables for each client. Further details are defined in in module B 5.7 Databases. Client separation on storage level The cloud services of each service model (SaaS, PaaS, IaaS) use cloud storage. Mechanisms for the separation of storage areas for different clients must be applied. A logical separation of storage resources via LUNs with client-related source and target address is possible. A SAN is segmented by dividing it into zones (zoning). The implementation of separation mechanisms in SAN is described in S Protection of SANs by segmentation. Detailed implementation instructions are provided in module B Storage systems and storage networks. Client separation on network level The prerequisite for consistent multi-tenancy is a separation on network level. In particular for the provisioning of cloud services, it is required that the cloud management installs separate networks automated on the basis of cloud service profiles. Correspondingly, the administration systems must implement network separation configurations from the cloud administration software for the network components. Multi-tenancy is accomplished via the separation of VLANs, by corresponding routing settings (by access check lists etc.) or by virtual firewalls. Appropriate safeguards from the network layer must be taken into account for each safeguard: - S Secure configuration of a network for virtual infrastructures - S 4.82 Secure configuration of active network components When establishing networks, the cloud management must ensure that the management network of the cloud service provider is isolated from the data network of the cloud services. In this context, the network can also be isolated using the network separation mechanisms mentioned above which are used for multi-tenancy, whereas the physical separation of the management network should be preferred. Client separation in the administration software for virtual or managed private cloud services Virtual or managed private cloud service can also be referred to as "DataCenter as a Service". This term describes complex IT infrastructures (virtual machines, networks incl. network coupling elements and storages) which are offered by the cloud service provider. By request of the cloud Page 72 of 98

73 S 4.CM.16Consistent separation of clients from the cloud services service customer, multi-tenancy can also be made for the administration of the cloud service provider. In this case, the cloud service provider must ensure that a dedicated cloud administrator runs the private cloud services of the cloud service customer. This must be implemented by a controlled authorisation and role concept which restricts the access to the administration functions of the private cloud by person-related accounts to authorised cloud administrators. These requirements must be taken into consideration when selecting a cloud administration solution. (see S 4.CM.06 Selection of cloud components). Review questions: - Is multi-tenancy consistently implemented at the relevant cloud components? - Are separation mechanisms consistently observed for the duplication of cloud services? - Are checks made for consistent separation? - Are there any responses of cloud components which prove the separation of clients? - Was there a check of the configurations for multi-tenancy in the cloud service profiles? Page 73 of 98

74 S 2.CM.17Controlled administration of users and authorisations in cloud computing S 2.CM.17 Controlled administration of users and authorisations in cloud computing Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrator, Specialists Responsible A central identity management and a role-based authorisation management should be used for the users of the cloud service provider as well as for the users of the cloud service customer (cloud clients). In general, it is not recommended to grant more access rights to data and information than are necessary for the task accomplishment of the application (Need to know and Least privilege principles). In addition to the processes regarding the setting up of users and authorisations, controlled processes regarding the removal (de-provisioning) of users and authorisations must be set up as well. This can be accomplished by blocking or deletion. The cloud service provider must ensure that the accounts ("identities") and authorisations of cloud service users to be blocked or deleted must be removed from all involved levels of the cloud IT infrastructure. The rights can be reliably removed from all involved areas e.g. operating system accounts, storage areas (cloud storage), accounts in the self service portal, database using a central system for authorisation administration. User accounts and authorisations should be verified on a regular basis (e.g. twice a year). In this context, it is necessary to check whether the created users are still registered as active users (otherwise, they must be blocked or deleted) and whether the roles and authorisations which they were assigned are still correct. Substitution arrangements must be observed. Users of the cloud service provider and cloud service customer The user administration (identity management) of the cloud service provider must be classified in two categories. On the one hand the staff of the cloud service provider and on the other hand the cloud service users of the cloud service customer (cloud clients). For the latter it is required to distinguish whether the administration of the cloud service users is accomplished by the cloud service provider, or whether the cloud service provider only provides the technical equipment (as for IaaS), and the cloud service users are administered by the cloud service customer. For user administration, an identity management operating beyond the organisational borders (Federated Identity Management, FIDM) can be involved or associated, provided that well-established standards (e.g. Security Assertion Mark-up Language SAML) and secure authentication procedures are used. The authorisation administration (authorisation management) has a similar structure as the user administration: You can distinguish between the authorisations of the cloud service provider staff on the one hand and the cloud service users of the cloud service customer on the other hand. The cloud service customer can grant the cloud service users only as many rights as are provided by the cloud service provider in the cloud service model. Page 74 of 98

75 S 2.CM.17Controlled administration of users and authorisations in cloud computing Users, roles and rights provided by the cloud service provider Cloud service providers should organise the assignment of rights based on roles with each role including certain authorisations. The users are then granted certain rights by the assignment of certain roles. In this context, for example, roles for the following areas might be helpful which can be assigned to persons or systems: - cloud service profiles - virtualisation hosts (starting, stopping and migrating virtual IT systems, assignment of physical resources) - network - storage system - self-service portal - billing - reporting - middleware (database, web server) It must be possible for each person or each system to use several roles, depending on the task, in order to get the rights required to fulfil the task. For example the automatic process of provisioning a new cloud client must have several roles because it requires several rights. Super users which have all rights in all areas must be avoided. Users, roles and rights provided by the cloud service customer The roles for the use of SaaS and PaaS offers are defined by the cloud service provider and provided for the cloud service customer. They are adapted to the different offers of the cloud service provider which can be accessed by the cloud service users of the cloud service customer. In case of IaaS offers, the cloud service customers are completely free on the virtual machine and can/must establish their own administration for users, roles and authorisations. There are usually at least two different kind of roles: privileged and normal user. - Privileged users administer the use of the cloud service through the staff (cloud service user) of the cloud service customer. They can usually add or delete new users, or assign or withdraw roles. If the cloud service provider provides the cloud service customer with different options of cloud services or different cloud services, the privileged user can enable these services or options for the normal users. To this end, the cloud service provider provides an interface (as web service or as web application in the self-service portal). Thus, user information is forwarded to the cloud management by the cloud service provider, who assigns appropriate authorisations. The cloud service customer can decide which rights are granted to the cloud service user or if any rights are granted at all. The cloud service customer must administer these rights and establish appropriate internal processes to this end. The cloud service provider must set up the corresponding basic conditions and specify the number of users allowed to be created and the number of resources allowed to be assigned. This is necessary to avoid any massive abuse. - The normal users are the actual users of the cloud service. They usually have no or only very restricted capabilities of administering the identities or the rights of cloud services. In particular it should not Page 75 of 98

76 S 2.CM.17Controlled administration of users and authorisations in cloud computing possible for any normal user to change their own rights (and thus their access capabilities). In case of private users, who are not contemplated in this document, both the roles of privileged and normal users are combined in one person which, however, should be avoided for business applications. Otherwise, the cloud services might be used in an uncontrolled way. If the cloud service provider assumes the authorisation administration for a cloud service customer, appropriate processes between both parties must be established. These processes must ensure that the cloud service provider acts verifiably for the purpose of the cloud service customer. Separation of different cloud service customers In some cases and in case of major cloud service customers, cloud service providers might be confronted with the requirement to allow only certain administrators to administer the offered cloud service. Then, the roles and rights management (authorisation administration) of the cloud service provider must also be multi-tenant in order to avoid the administration of the services of a client by unauthorised persons. Access of cloud administrators to cloud service customer data If possible, the administrators of the cloud service provider should neither be authorised to access the data and applications of cloud clients nor intervene in the authorisation administration of SaaS or PaaS applications if these are administered by privileged cloud service users. For troubleshooting, however, it might be necessary that the administrators of the cloud service provider have access to the data of the cloud clients. To this end, technical safeguards must be established which restrict the access to the areas relevant for troubleshooting. Moreover, this authorisation should only be valid for a clearly defined period. Documentation The following information on the user and authorisation management must be systematically (history) documented: - which function is equipped with which access rights taking the functional separation into account, - which groups and/or profiles are set up, - who fulfils which functions, - which access rights are assigned to whom within the scope of which role. Review questions: - Has a role-based authorisation concept for the administrators of the cloud service provider and the cloud service users of the cloud service customer been implemented? - Have super users been avoided? - Have all created users and their authorisations including the change history been documented? - Is there a process which regularly checks the existing user accounts? Page 76 of 98

77 S 2.CM.18Secure and complete deletion of cloud service customer data S 2.CM.18 Secure and complete deletion of cloud service customer data Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrators Due to different reasons, it may become necessary that the cloud management must securely delete parts of the database or all data of a cloud service customer. For example the obligation to retain data may expire, the cloud service customer may be informed by third parties about extraordinary requirements for the deletion of data, or the contract ruling the cloud services may be terminated. The periods for deletion as well as the way the cloud service provider is requested to carry out the deletion are usually part of the contractual agreement between the cloud service provider and the cloud service customer. This should be taken into account in the contractual agreement (see safeguard S 2.CN.X Contractual agreement from the use of cloud module). However, the deletion of cloud service customer data does not only refer to data which is administered within the cloud services but also to data for cloud management processes such as billing data, role and authorisation assignment data, logging and cloud contract data (e.g. in the cloud repository) unless legal stipulations require a mandatory storage for the cloud service provider to be observed. Cloud service providers must be in the position to delete the data of all virtual and physical storage media in compliance with the contractual agreements. In order to ensure that the data is completely deleted, the cloud service providers must be able to identify the storage location of all data, i.e. they must know which data has been stored on which storage systems and on which storage media. Safeguard S 2.S07 Secure data deletion in Sans (safeguard from the module cloud storage) must be implemented for the deletion of the data from the cloud storage. For the secure deletion or destruction of information, suitable methods must be available on the one hand, as well as suitable devices, applications, or services on the other hand. To this end, the cloud service provider must define in writing a process for secure deletion (according to the concluded contractual agreement) and assign responsibilities for implementation. For certain specifications and processes, the specifications of module B 1.15 Deleting and destroying data must be taken into account provided that they can be transferred to cloud computing. Review questions: - Are there processes and responsibilities informing how individual information of the whole database can be deleted by cloud service users according to the contractual agreements? - Are devices, applications and services available for the secure deletion as per contract? - It it possible to delete user data as well as administrative data on request? Page 77 of 98

78 S 2.CM.19Controlled provisioning and de-provisioning of cloud services S 2.CM.19 Controlled provisioning and de-provisioning of cloud services Initiation responsibility: Head of IT Implementation responsibility: Administrator, Specialists Responsible The elasticity in cloud computing allows for the prompt provision of cloud resources for the cloud service customers. For this purpose, the controlled provisioning and de-provisioning of cloud services is required. Provisioning is the assignment of a cloud service to a cloud service customer and the associated provision of the necessary cloud resources as well as their configuration. Cloud resources include CPU, memory, data storage, virtual networks etc. Templates with the stored information on cloud resources and configurations are used for provisioning. These templates are referred to as cloud service profiles. De-provisioning, the counterpart of provisioning, is the revoking of the assignment of the cloud resources of a certain cloud service to a certain client (cloud service customer). Provisioning happens at the beginning of the utilisation of a cloud service by the cloud service customer, de-provisioning at the end. The processes and work flow defined for all phases of the administration of a cloud service must be established and maintained. A process with responsibilities, taking the whole life cycle of a cloud service into account, must be saved and documented for the controlled provisioning and de-provisioning of cloud services. The process for the provisioning and de-provisioning of cloud services focuses on the following phases: Preparation: Planning of cloud services The cloud services must be planned, and the requirements identified by the cloud service provider must be recorded. To this end, safeguard S 4.CM.02 Planning of cloud service profiles must be implemented. This planning results in the reference architecture (blueprint) of a cloud service. This includes the required cloud resources (CPU, memory, network connection and network separation, network storage) and their quantity structure for each cloud service customer. Planning and implementation of provisioning Cloud service providers must be in the position to control the provisioning of cloud services on the basis of the current demand. The steps for provisioning must be prepared. The set of information regarding the properties and types of cloud services and the associated data regarding the service level are stored in a cloud service catalogue of the cloud service provider. The service catalogue also includes information on which cloud service customer may use selected cloud services and under which conditions. If the cloud service is offered through a portal (a so-called self-service portal), it must be taken into account for provisioning that, depending on the cloud service, the cloud service customer can directly influence the configuration to be set. Correspondingly, logic limits for resource assignment must be set for the portal and the cloud service profile. In such cases, the request of a cloud Page 78 of 98

79 S 2.CM.19Controlled provisioning and de-provisioning of cloud services service customer via the portal would be the initiator for the provisioning process. The cloud service provider must set up automatic or manual test and approval steps prior to the automated provisioning of cloud services. The provisioning and de-provisioning with cloud service profiles allows the administrator to illustrate the development of complex automation tasks in processes. Subsequently, the processes can be quickly accessed and started directly via the administration software of the cloud or via different triggering mechanisms. The manual work steps for cloud administrators must be defined and documented in the form of work instructions, and the responsibilities for the work steps must be determined and announced. The correct implementation of the configurations on the basis of the cloud service profiles must be tested for the automatically provided cloud services. Moreover, the configuration must be checked on a random basis, or it must be shown by means of the cloud administration solution that the cloud services are provided correctly and in compliance with the requirements. The implementation of configurations and safeguards must be ensured at all levels of the cloud infrastructure. Therefore, the configuration settings in the cloud service profiles and in the provisioned cloud services must be checked. The cloud service provider must particularly ensure the trouble-free and correct communication between cloud administration software and the cloud elements (element manager). Termination of cloud services: De-provisioning If the cloud service customer terminates the applied cloud service or if the contract expires, the controlled termination of the cloud services must be ensured. After the de-provisioning within the scope of the decommissioning of cloud services, the configuration from the provisioning process must be reversed. The cloud service provider must make sure to release the cloud resources, and that the cloud services including the accounts and the authorisations of the cloud service users are deactivated. The administrators of the cloud service provider must retrace and check that the cloud resources (memory, VLANs, virtual machines) have been released. Depending on the cloud infrastructure, the release of the cloud resources must also be checked for the administration components (element managers). Review questions: - Have the responsible persons for the provisioning and de-provisioning of cloud services been defined and adequately communicated? - Have the manual work steps of the cloud administrators for the provisioning of cloud services been documented? - Has the planning of cloud services been accomplished on the basis of the requirements of the cloud service users? Does planning result in a reference architecture for cloud services which reflect the requirements? - Is the correct implementation of automatically provisioned cloud services checked, and is the requirement-based configuration of the cloud service understood? - How does the cloud service provider ensure after the termination of a Page 79 of 98

80 S 2.CM.19Controlled provisioning and de-provisioning of cloud services cloud service that the corresponding resources and authorisations are denied? Page 80 of 98

81 S 2.CM.20Reporting and communication to the cloud service customers S 2.CM.20 Reporting and communication to the cloud service customers Initiation responsibility: IT Managers, Specialists Responsible Implementation responsibility: Specialists Responsible There are two main forms of communication between cloud service providers and cloud service customers: - Reports of the cloud service provider to the cloud service customers - Messages of the cloud service customers to the cloud service provider Below is a description of the reporting system first and then of the communication system. Reporting system The cloud service is described in the service level agreement (SLA) or in the cloud service catalogue. The precise agreements regarding the properties of the cloud service are saved here. Minimum requirements for communication and respond times must be agreed in order to make service level management possible for the cloud service provider and the cloud service customer. A regular reporting system should be implemented so that the cloud service provider can provide the cloud service customer with proof of the service level (e.g. availability): Reports with information regarding service level, scope of utilisation by the cloud service customer (e.g. utilisation of the booked storage space) and costs should be sent to the cloud service customers on a regular basis. The service level agreement or the cloud service catalogue must define which reports and rated values are to be provided for the cloud service users at which time intervals. The key performance indicators for service level rating and the kind of reporting as well of the kind of provisioning must be defined (e.g. via a web dashboard of a self-service portal for cloud service customers). On the basis of the ratings and key performance indicators in the SLA, it should be possible for the cloud service customer to understand to what extent the cloud service provider has achieved the key performance indicators defined in the SLA. The logging of the cloud service forms the basis for the ratings. Communication system Possible malfunctions or failures of the resources (e.g. virtualisation server, virtual machine, load balancer) must be promptly detected such that countermeasures can be taken. Interfaces for the technical operation in case of security problems (message to the administrator) must be defined accordingly. The cloud service provider must establish an interface with his existing information security incident management and define appropriate contact persons (see also S 3.46 Contact persons for security questions, as well as S 6.60 Specification of reporting paths for security incidents). All cloud service customers should be familiarised with the contact persons for security questions and with the reporting paths for security incidents. Any malfunction reported by the cloud service customers must be forwarded to the operational malfunction management of the cloud service provider and be processed there. Review questions: Page 81 of 98

82 S 2.CM.20Reporting and communication to the cloud service customers - Does the cloud service customer receive regular and transparent information on the performance rendered by the cloud service provider? - Were the cloud service customers familiarised with the contact persons to whom they can report malfunctions? Page 82 of 98

83 S 2.CM.21Secure automation of cloud control processes S 2.CM.21 Secure automation of cloud control processes Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrators The purpose of cloud computing is to provide a separated pool of configurable cloud resources (e.g. networks, servers, storage systems, applications and services) with only minimal administration efforts or little interaction by the cloud service provider. For this purpose, the request of cloud services and their provisioning must be accomplished in an automated way. The challenge for cloud service providers is to provide the resources within a very short time ensuring information security. At the same time, for economic reasons, cloud service providers try to keep the server utilisation of the cloud infrastructure high and to minimise the running costs. The automation of cloud control processes includes the script-controlled sequence of configurations via the cloud administration software. The automation of the cloud control processes is considered as secure if the script-based configurations are correctly implemented. Control processes in cloud management The cloud management includes several control processes for the provision, operation and billing of cloud services to a level which was agreed. The control processes include the following: - Provisioning and de-provisioning (also: Orchestration) - Registration of cloud services in the service catalogue - Monitoring of cloud resources and cloud service utilisation - Access management for cloud services - Maintaining of cloud services Cloud control processes can be simplified for the administration of a large number of cloud services by automation. Secure automation for the provisioning and de-provisioning of cloud services Thresholds for the cloud resources must be specified for the secure automation in the provisioning process. Once the thresholds are exceeded, there is a danger that not enough cloud resources are available for all cloud services. This must also be taken into account for portals for the direct request of cloud services by the cloud service customer. In the so-called self-service portals, the requests made by cloud service customers must be matched with the thresholds. Thresholds must be defined for the utilised bandwidth for the provision of cloud services, for the processing capacities (CPU and memory) and for the storage. The thresholds for SaaS offers might also include the number of cloud service users of a cloud service customer, the number of transactions, etc. The resource management of the cloud administration server is responsible for the automated allocation of processor and memory resources, which operate on the same physical server, to the virtual machines for the cloud services. For the automated provision of cloud services, the cloud service provider must define the minimum, maximum and proportionate resource shares for CPU, memory, hard disk and network bandwidth. Page 83 of 98

84 S 2.CM.21Secure automation of cloud control processes The default settings for automated configuration changes by the cloud administration software must be planned and the process steps must be defined. These process steps include the automated steps for load distribution and the prioritisation of cloud services (taking into account the different service levels of the cloud clients and more). The cloud service provider must make prioritisations for the cloud service customer; in case of resource bottlenecks, he must control which cloud service must be prioritised with regard to cloud resources. If the cloud services are regularly changed, e.g. peak loads or "waves" in the distribution of the cloud service utilisation, the automated configuration must be scheduled. Automated provisioning and de-provisioning requires the correct interaction of the cloud resources. This is only possible if the different products and cloud elements communicate with each other via defined interfaces and protocols. The integrity and correctness of the interactions between the administration components (element manager) of the physical and virtual cloud resources and the orchestrated administration software is especially important. In order to ensure the integrity and correctness of the automation processes for cloud control processes, organisational and technical safeguards are required. These are described in the following paragraphs. Organisational safeguards: The cloud service profiles must be checked. The check must be carried out for new or changed cloud service profiles. In this process, the configurations of the cloud resources must be compared with the target configuration provided in the requirements of the cloud services. In order to check the compatibility of the cloud components with each other, the manufacturer of the cloud components should be questioned with regard to the compatibility and connectivity of the applied products. Technical safeguards: The communication between the cloud components must be secured. To this end, a secure bi-directional communication providing integrity must be installed between the cloud components. The installation must be made on the basis of the applied protocols for the transmission of automated configuration changes. Either management protocols are used which already include mechanisms ensuring integrity, or the transmission paths must be encrypted. For example, SNMP version 3 could be used in order to achieve encryption and adequate authentication. For detailed implementation, safeguard S Selection of a suitable network management protocol must be applied. Secure automation of the registration of cloud services The cloud resources allocated for provisioning and the provided service levels (e.g. storage) must be filed in a directory in the cloud administration, the so-called cloud service catalogue. The cloud administration software must ensure that an updated overview of the active cloud services can be provided in real-time. The cloud service catalogue must contain the automatically provided cloud services and the correct allocation to the cloud service customers. It must be ensured that the information in the cloud service catalogue is correct and made by information of integrity in the cloud administration software. Therefore, the cloud service provider must compare the information of the cloud service catalogue with the actually offered cloud services and their service level, as well as their allocation to the cloud service Page 84 of 98

85 S 2.CM.21Secure automation of cloud control processes customers. The access to the cloud service catalogue or cloud repository must be restricted due to the integrity requirements, and all changes must be logged. Monitoring of cloud resources and cloud service utilisation The monitoring of cloud resources and cloud service utilisation is accomplished by the logging of events at the components of the cloud infrastructure. The protocols must be evaluated in a (partially) automated way, and the main information on cloud monitoring must be summarised (by correlating the events). The thresholds (minimum/maximum) for the utilisation of the cloud resources must be defined, and the logging information must be evaluated with regard to these thresholds. On the basis of resource monitoring, either the cloud administration software must re-organise the cloud resources (e.g. prioritised cloud services can be supplied preferentially), or the cloud administration must be alarmed. Automation of the access management for cloud services When providing cloud services, the access to these services must be controlled. To this end, access protection must be installed which must already be taken into account for the cloud service profiles. In particular for the automated provisioning of cloud services, the authentication of the cloud service users with access protection must be available. As an alternative, the access protection with authentication of the authorised cloud service users may be installed upstream. E.g. by an identity management operating beyond the organisational borders, also referred to as Federated Identity Management (FIDM). Automation for maintaining cloud services For maintaining the operation of cloud services, it is necessary to use automated mechanisms which protect their availability. This automation is achieved by the network-based components of the load balancing, by server operation in a cluster and by automated virtualisation functions (e.g. automatic allocation of virtual resources). Review questions: - Have thresholds (minimum/maximum) for the cloud resources and reactions in case of the infringement of these thresholds been defined? - Are the cloud services and the allocation of cloud resources prioritised? - Is there a check in the framework of provisioning and de-provisioning as to whether the automated configurations are correct? - Is there any assurance that the automatically controlled cloud components are compatible with each other and communicate correctly with each other? - Are management protocols used for automated configuration which are secured in terms of integrity? - Are the contents of the cloud service catalogue comparable with the actually offered cloud services and their service level? - Is logging information at cloud components (partially) automatically evaluated? - Do the automatically provided cloud services include access protection Page 85 of 98

86 S 2.CM.21Secure automation of cloud control processes mechanisms, and do they require authentication? Page 86 of 98

87 S 4.CM.22Introduction to cloud management S 4.CM.22 Introduction to cloud management Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrator, Head of IT The following properties are characteristic of cloud services: - Cloud resources (e.g. computing power, memory, networks, storage networks) are automatically provided by the cloud service provider (via so-called self-service portals) with minimal interaction or without interaction at all. - The cloud services are available through the network via standard interfaces (e.g. HTTP). Thus, they can be used by different clients. - The resources of the cloud service provider are provided in a shared pool which is used by many cloud service customers (multi-tenancy). - Cloud services can be provided quickly and flexibly. Cloud services are provided in a highly automated manner. - Resource utilisation can be measured and monitored, and the corresponding evaluation can be provided for the cloud service customer. Definition of cloud computing Cloud computing is understood as the offering, using and billing of IT services dynamically adapted to the requirements via a network. Here, these services are only offered and used by means of defined technical interfaces and logs. The term of cloud computing is used in the IT-Grundschutz catalogues according to the definition above. Any simple web application is usually not referred to as cloud computing. There are different provisioning models for cloud computing. The different provisioning models are defined as follows: - In a private cloud, the cloud infrastructure is operated for one organisation only. It may be organised and managed by the organisation itself or by a third party; it may be located in the data centre of this organisation or of an external organisation. - If cloud services can be used by the public or a larger group, such as a whole industrial sector, and if the services are provided by a provider, you speak of a public cloud. - In a community cloud, the infrastructure is shared by several organisations with similar interests. Such a cloud can be operated by one of these organisations or by a third party. - Any shared use of several cloud infrastructures each of which is independent via standardised interfaces is referred to as a hybrid cloud. The provisioning models are thus classified by how much cloud service customers use a cloud and in which constellation. Besides the provisioning models, there are also different service models. The service models are classified according to the type and scope of the provided cloud services: - Infrastructure as a Service (IaaS): IaaS offers IT resources such as computing power, storage or networks as a service. Cloud customers buy this virtualised and highly standardised basic service as a basis for the establishment of their own services for internal and external use. For example, cloud service customers can rent computing power, memory Page 87 of 98

88 S 4.CM.22Introduction to cloud management and data storage and use this to run an operating system with applications of their choice. - Platform as a Service (PaaS): PaaS providers provide the complete infrastructure and offer the customer standardised interfaces on this platform which are used by the services of the customer. This platform may, for example, provide multi-tenancy (separation of customers), scalability, access control, database access, etc. The cloud service customer is not responsible for the layers below (operating system, hardware) but he can run his own applications on the platform form, and the cloud service provider usually offers tools for the development of these applications. Compared to the basic services offered in IaaS, PaaS offers additional platform services, such as database, access control or web servers. - Software as a Service (SaaS): All application offers which correspond to the criteria of cloud computing are part of this category. There is a limitless range of offers. SaaS offers are based on the basic IaaS offers and the PaaS platform services with pre-configured applications; they offer the cloud service users a package which they can use immediately. Examples are personal information management, financial accounting, word processing or collaboration applications. Roles and responsibilities in cloud computing The cloud service provider (CSP) offers different categories of cloud services (IaaS, PaaS, SaaS). The individual person utilising the cloud service is referred to as cloud service user. If an organisation offers its employees the use of cloud services by signing a contract with the cloud service provider, the organisation acts as the cloud service customer. If the cloud service is used privately, cloud service customer and cloud service user are identical. Administration components in cloud computing A virtualisation software is used for the control and administration of the virtual infrastructure of the cloud. For the administration of the cloud itself and its logical infrastructure, a software is normally used as well. This software is referred to as cloud administration software. The virtualisation software and the cloud administration software can be installed on a shared or on separate physical or virtual IT systems. The server for the provision of the virtualisation software is referred to as virtualisation server. The server for the provision of the cloud administration software is referred to as cloud administration server. If virtualisation software and cloud administration software run on a shared IT system, the virtualisation server also acts as the cloud administration server. Reference model for cloud computing A cloud reference model covering the main aspects is used to describe the operating processes of cloud management. The basis for module B 5.X Cloud management is the reference model of the Internet Engineering Task Force (IETF) (Cloud Reference Framework, available as a so-called internet draft). In this model, the IETF has defined the components of a cloud environment, Page 88 of 98

89 S 4.CM.22Introduction to cloud management their interfaces and the control of cloud services. The reference model is structured in layers for cloud services, virtualisation (virtual machines for cloud service operation) and physical components (as carrier for the virtual machines) describing their interaction. These layers are referred to as horizontal layers. These layers are: - Application layer: Here, service models (IaaS, PaaS, SaaS) are administered and cloud services are configured. This layer defines the requirements for the cloud services providing them to the cloud service users. - Resource control layer: This layer administers the virtual resources of the cloud infrastructure for efficient, reliable and secure provisioning. By means of authentication checks, the resource control layer ensures that the administered cloud resources are provided for the correct cloud services and thus for the correct cloud service users. Moreover, the resource control layer allows for the efficient allocation of the virtual cloud resources to the hardware components of the cloud infrastructure. - Virtualisation layer: It is difficult to allocate the physical hardware components to different clients. Whereas virtual resources can be allocated and released as needed. Therefore, the physical cloud resources are converted into virtual cloud resources via the virtualisation layer. The virtual resources are administered in a resource pool and provided for or withdrawn from the cloud service customers as needed. - Layer of physical resources: The layer for the administration of physical cloud resources assumes the integration and provisioning of hardware components for the cloud. The hardware components include the following: Computing power (CPU), memory, storage networks and their connection, network cards and network connections, network bandwidth and network ports. Interacting with these layers, the reference model implements cloud management as a vertical layer effecting all horizontal layers and acting cross-sectionally on the resources to be administered (IaaS, PaaS, SaaS). The emphasis among others is on the fact that the security management and the safeguards act cross-sectionally on all horizontal cloud layers. In the vertical layer of the cloud management, IETF provides a number of tasks and functions: - Configuration management, - provisioning and registration services, - monitoring and reporting, - administration of the service levels (service level agreements), - security. The typical tasks of cloud service providers in cloud management include: - the provision of a service catalogue describing the cloud services offered; - the cloud configuration for provisioning and de-provisioning, respectively, of cloud resources (including: virtual machines, virtual data memories, virtual networks) and cloud service profiles (defined configurations for cloud resources used to provide the services offered); - the allocation of physical and virtual resources to the cloud service users and the configuration of these resources; - the access management for cloud resources and the authentication of Page 89 of 98

90 S 4.CM.22Introduction to cloud management access; - the monitoring of provided cloud services and resources in order to comply with the guaranteed service levels; - the billing of the cloud services used (on the basis of the service catalogue) in a traceable way for the cloud service customer. The following figure shows the reference model for cloud computing used for IT-Grundschutz: Figure 3: Reference model for cloud computing (overview) Page 90 of 98

91 S 2.38Division of administrator roles S 2.38 Division of administrator roles Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrators Many network operating systems offer the option to divide up the administrator role and to assign administrative activities to different users. Thus, the following administrator roles can be set up, for example under Novell Netware 3.11: Workgroup Manager, User Account Manager, File Server Console Operator, Print Server Operator, Print Queue Operator. Under Windows NT, defined administrator roles can be created by assigning user rights in a targeted manner to individual users or, even better, to groups. In addition to the group of administrators, groups such as power users (i.e. administrators with restricted rights), backup operators, print operators, server operators as well as reproduction operators must be mentioned in this respect. In addition to this, additional roles can be defined by means of the explicit assignment of user rights (see also S Planning the use of Windows Server 2008). If there are administrator roles for special tasks, they should be used. Especially if several persons have to be entrusted with administrative tasks in large systems, the risk of the outsized power of the administrator roles can be reduced by the corresponding division of tasks so that the administrators cannot carry out any unauthorised or unintentional changes to the system in an uncontrolled manner. Despite dividing up administrative activities, in most cases the system also automatically opens an account for an administrator that is not subject to any restrictions, i.e. the supervisor. The supervisor password should, if at all, only be known to a small group of people. It must not be known to any of the subadministrators to ensure that they cannot extend their rights in this way. The password must be stored securely (see S 2.22 Escrow of passwords). The supervisor login can be additionally protected by applying the two-person-rule, e.g. by organisational safeguards such as a shared password. Here, the password must have a longer minimum length (12 or more characters). In this respect, it must be ensured that the full minimum length of the password is checked by the system. Review questions: - Are there different administrator roles for subtasks? - If there is an existing supervisor account: Is the supervisor password only known to a minimum group of people? - If there is an existing supervisor account: Is the supervisor password stored securely? Page 91 of 98

92 S 4.430Analysing the logged data S Analysing the logged data Initiation responsibility: IT Security Officer, Head of IT Implementation responsibility: Administrator Normally, a large amount of log files is generated within an information system. Before the log entries can be analysed, the data must be normalised. Normalisation ensures that the different data formats of the log-generating systems are converted to a uniform format. Before analysis it is furthermore important that the relevant data is limited in order to reduce the amount of logged data. This is performed with the help of filter options, aggregation, and correlation of the data (see S Selecting and processing relevant information for logging). These safeguards are particularly important when logging is performed centrally. Time synchronisation is another important aspect regarding the analysis of the logged data. In order to be able to identify attacks or malfunctions across several IT systems and applications, an identical time should be set on every system. Central time servers can be used in order to ensure that all systems have the same time even in a large information system (see also S Secure time synchronisation for centralised logging). These servers provide the system time using the Network Time Protocol (NTP), for example (see S Use of a local NTP server for time synchronisation). All further systems in the information system can be synchronised with this time. For an alarm function, the logged information must be analysed promptly. During analysis, security-critical events are considered without any delay. Additionally, relevant data from already existing log files is extracted and used for the analysis. The analysis must particularly focus on deviations from the normal behaviour, configuration errors, and error messages in order to gain an overview of all relevant events within an information system. In order to be able to promptly identify a relevant log entry, it is possible to use suitable algorithms and analysis technologies such as signature identification and threshold analysis. These technologies are often used by IT early-warning systems. As soon as an attack is detected, an alarm should be triggered so that immediate intervention against the threat is possible. Page 92 of 98

93 S 4.430Analysing the logged data Figure: Basic procedure for an IT early-warning system In order to be able to comprehend the events and the log entries for a possible retention of evidence, a report should be drawn up upon analysis. Many logging applications offer a web interface in order to also represent the analysis result graphically. This way, possible trends can be better identified. The web interface can also be used to define any analysis views and filters. If the logged data is analysed centrally, it is possible to identify complex relations within the information system and to browse for operation or security incidents within the information system. Therefore, the logged data should be archived for future analyses. Along with the internal requirements regarding the retention period, it must be checked in advance which legal or contractual retention periods are applicable to log files. A minimum retention time may be specified in order to guarantee the ability to trace all activities, and a deletion requirement may apply due to data protection regulations (see also S Data protection guidelines for logging procedures). Review questions: - Is the data normalised before analysis? - Is the information system operated in a time synchronised manner? - Is a report drawn up after the logged data was analysed? - Is the logged data archived for future analyses? - Are legal provisions taken into consideration when archiving the logged data? Page 93 of 98