Security Property Development and Analysis of Cloud Infrastructure

Transcription

1 SEcure Cloud computing for CRitical infrastructure IT Contract No Deliverable: 5.2 Cloud assurance profile and evaluation method AIT Austrian Institute of Technology ETRA Investigación y Desarrollo Fraunhofer Institute for Experimental Software Engineering IESE Karlsruhe Institute of Technology NEC Europe Ltd. Lancaster University Mirasys Hellenic Telecommunications Organization OTE Ayuntamiento de Valencia Amaris

2 Document Control Information Title Deliverable Cloud assurance profile and evaluation method Editor Aleksandar Hudic (AIT), Markus Tauber (AIT) Contributor(s) Matthias Flittner (KIT), Roland Bless (KIT) and Santiago Caceres (ETRA), Mari Matinlassi (MIRASYS), Frank Pallas (KIT), Silvia Balaban (KIT), Ani Bicaku (AIT), Silia Maksuti (AIT) Red highly sensitive information, limited access for: Classification Yellow restricted limited access for: Green restricted to consortium members White Public Internal reviewer(s) Andreas Mauthe, Simon Oechsner Review Status Draft WP manager accepted Coordinator accepted Requested deadline 31/12/ Versions Version Date Change Comment/Editor /11/21 Initial Creation Aleksandar Hudic, Markus Tauber (AIT) of Deliverable /12/28 Revision - Aleksandar Hudic, Markus Tauber (AIT) Second Iteration /12/05 Version for review Andreas Mauthe (ULANC), Simon Oechsner (NEC) /12/18 Incorporated Aleksandar Hudic, Markus Tauber (AIT) comments from review /12/19 Final Review Markus Tauber, Christian Wagner (AIT) Deliverable 5.2 Page 2 of 60

3 Abstract In this work a novel assurance evaluation methodology, motivated by common criteria, is presented. It allows to abstract over monitoring artefacts relating to high-level security properties and dependencies between components in a multi-level and multi-tenant Cloud infrastructure. A typical Cloud based application consists of multiple components which reside in different layers in the Cloud stack (e.g. the virtual service, virtual machines, and physical servers). The dependencies between these components may change over time. Our flexible assurance evaluation methodology allows continuous aggregation of measurable information reflecting the high-level security properties status of individual constituent components of a virtual service or any other target of evaluation, in such an environment. This aggregated information is represented as Assurance Profile and can be used to categorise overall application security in terms of Assurance Levels. These are determined by assurance dependency policies, which result in specific assurance profiles per target of evaluation. It gives the owner of the evaluated service (target of evaluation) an overview of the security of his service, without requiring continuous detailed manual analyses of log files. Central building blocks of the method, including a conceptual assurance evaluation framework have already been published. These are an overall approach description[hht + 14], the flexible policy driven framework [HTL + 14] and preliminary ideas regarding an evidence gathering mechanism for collecting raw data from the Cloud stack[fpt13] relating to security properties. Deliverable 5.2 Page 3 of 60

4 Contents 1 Introduction Motivation Contributions Legal Issues Outline of this Deliverable State of the Art Related work on Assurance Methodologies State of the art open source monitoring tools Security Requirements for Critical Infrastructures in the Cloud Catalogue of security properties Confidentiality Integrity Availability Security Properties Compliance with State of the Art Monitoring Tools - a Summary 25 4 Assurance Assessment Framework and Methodologies Assurance objectives Assurance Framework Evaluation Evaluation scenario Correlation with the SECCRIT demo scenario Evaluation policies and security properties Configuration examples and results Conclusion and Future Work 53 A Extended Assurance Catalogue 54 B State of the Art Monitoring Tools 55 C Linkage to other deliverables and tasks 56 Deliverable 5.2 Page 4 of 60

5 1 Introduction A transformation of processes in IT systems is taking place, it is triggered by the rapid propagation of the Cloud Computing paradigm across different domains and organisations. The National Institute of Standards and Technology (NIST) [MG11] depicts the Cloud architecture through a dynamic tree-layered service-provisioning model (infrastructure, platform and software - as a Service layer) capable of scaling services across distinct administrative and legislative domains. The main motivation for adopting Cloud technology is to increase efficiency and minimize IT costs by offering new concepts such as elasticity, scalability and on-demand resource provisioning. These properties make Cloud computing attractive, also for IT supporting critical infrastructures (CI) operations [JJD03, MCF03] (e.g. water, electricity, public transportation, healthcare system and telecommunication). CI are considered as the essential utility that drive economies and societies worldwide and their operations, (including IT systems used for operating them) have generally to adhere to strict regulations. As the operations of CI affect a lot of people, trust in the used technology is of utmost importance. IT Systems used for managing CI require large amount of resources, and hence CI providers often host their own infrastructure or may join resources with other similar organisations. If a single CI provider operates a dedicated infrastructure the provider may be large enough to have subsidiaries which also use this infrastructure. In any case multi-tenant and multi-layer issues apply in these scenarios in a similar way as for common IT businesses. In such a multi-tenant and multi-layer environment the introduction of scalability and flexibility adds some churn in dependencies between the used resources. Examples include a virtual service (e.g. a service analysing the monitored operational data, or data used for billing the utility usage), which is built on n load balancing virtual databases. Adding m virtual databases to the existing n on the fly increases the scalability of the overall service. This may result in adding resources with other properties than the existing constituent resource in the bespoken service. 1.1 Motivation In particular in a CI environment the users of a virtual service, have to be assured that certain security levels are maintained despite a changing environment. Established standards like ISO27002 are based on high-level definitions for security properties (e.g. strong passwords), which may be mapped to individual constituent components in a virtual service. The dependency between the components may have an effect on how security can be assured for the overall service. Due to the potential dynamic changes in the service compositions resulting from resource scaling operations the dependencies between components may change. This requires to analyse how high level security properties can be measured per component and define how continues aggregation of measured information can be achieved. Existing approaches that we address in related work section, only provide high level security property definition, or focus in their attempts to measure properties on performance metrics only. Deliverable 5.2 Page 5 of 60

6 1.2 Contributions Motivated by the current situation we propose an assurance evaluation methodology, based on Common Criteria[CC12], which form the contributions of this work, they include: a model for representing security properties to support measuring them a flexible and customisable framework, which aggregates security properties of individual constituent components of a virtual service (done under consideration of work from and with the liaison-project Cumulus - see joint publication[htl + 14]) a method which simplifies the aggregated information by determining a level of assurance depending on policies, and which allows continues evaluation identification (with CI and Cloud stakeholders, including SECCRIT demo partners) of a representative set of security properties; their categorisation; and an investigation on how they can be measured We refer to assurance, motivated by Common Criteria [CC12], as the likelihood for a service falling victim to a cyber-attack. A high assurance level means a low probability for this to happen. Security properties, based on measurable metrics, of constituent components contribute to the overall assurance level. The components can reside in different layers of the Cloud stack and may be categorised in different security classes. We base our Cloud stack terminology on the SECCRIT architectural framework [BFH + 14] and security classes, along with other terms on Common Criteria. The core concept of our approach is the representation of sets of these security properties as bit masks per a) component and b) per security class. This allows flexible policies in which the considered security properties can be prioritised depending on their position in the bit mask and policies for how such bit masks are being aggregated (i.e. dependency policies) to determine an assurance-level and -profile of the target of evaluation. These features are required for automatically re-evaluating the target of evaluation s assurance profile in the presence of a changing environment and to hence provide continuous assurance. The basic concepts and building blocks of this work have already been published, those are: the overall approach based on an analysis of state of the art [HHT + 14], the flexible policy driven framework [HTL + 14] and preliminary ideas regarding an evidence gathering mechanism for collecting raw data from the Cloud stack[fpt13]. 1.3 Legal Issues No personally identifiable information is collected for the development of the here presented method. This renders the legal template used in other SECCRIT deliverables as not applicable. 1.4 Outline of this Deliverable In the related work section we provide an overview of assurance related methodologies, state of the art on open source monitoring tools for Cloud and security requirements. In section 3 we provide information on how individual security properties can be measured, based on reviews and tests of existing monitoring software. In section 4 we detail the assurance framework and methodologies. Next, we evaluate our assurance method based on evaluation scenarios in various configuration examples, in section 5. Finally, we conclude this deliverable and give an outlook to future work in section 6. Deliverable 5.2 Page 6 of 60

7 2 State of the Art We analyse and summarize major existing guidelines, methodologies, standards, approaches related to assurance and critical infrastructure IT hosted on top of a Cloud ecosystem. We also review existing monitoring solutions for potential support in this context. In particular we investigate how the existing approaches tackle cross layer monitoring, security assessment, policy integration in assessment processes for services that rely on high security requirements. Furthermore, we investigate work on security requirements in a critical infrastructure IT and cloud context and support this with preliminary results from a survey on this topic. The survey is conducted as part of another SECCRIT task and still work in progress. 2.1 Related work on Assurance Methodologies Guidelines IT assurance Guide by COBIT The goal of COBIT s IT Assurance Guideline [COB07] is to support and guide enterprises to leverage the COBIT framework for a variety of IT assurance activities. The guide is designed to support the efficient and effective development of IT assurance initiatives, providing guidance on planning, scoping and executing assurance reviews using a road map based on well-accepted assurance approaches. The IT Assurance Guide provides assurance advice at the process and the control objective level. Furthermore, the guideline also implements the assessment processes with respect to the business plan, through the following three stages: planning, scoping and executing. The first phase defines the universe of the assurance (the observed entities), selects an IT control framework, defines the set of preferred objectives, performs high level assessment and risk assurance planning. The second phase defines the business model the IT goals and key processes, resources and custom control objectives. The final phase refines the understanding of the IT assurance subject and the scope of key control objectives, tests effectiveness and outcome of the key control objectives, provides the final conclusion and documents the impact on control weaknesses. The COBIT guideline offers a fine grained analysis of the system with in respect to business goals, however it lacks the support for critical infrastructure and assurance with respect to Cloud ecosystems, locality issues, and aggregation of assurance Information Technology Assurance Framework The Information Technology Assurance Framework (ITAF) [ITA13] is a comprehensive best practice guideline that provides design, guidance, implementation and reporting of IT audits and assurance assignments, defines concepts and terminologies with respect to IT assurance, and establishes a set of reporting and auditing requirements. ITAF is composed of three standard guidelines: General set of standards, Performance Standards and Reporting Standards. The framework also operates and addresses other guidelines such as COBIT, ITIL, (ISO)/IEC standards, IT Control Objectives, IT Governance Domain Practices and Competencies, within the scope of its work to assess the IT infrastructure. The framework adheres to the above mentioned standards as a set of relevant requirements of an IT professional dealing with IT assurance, and moreover tending towards a guideline for best practices for business and IT processes, with respect of assurance and audit standards. Deliverable 5.2 Page 7 of 60

8 Therefore, making it a well-structured and comprehensive best practice capable for IT business processes evaluation. The ITAF derives best practices and strategic approaches to provide holistic assurance of a system, however it does not address the critical or cloud infrastructures Cloud Computing Information Assurance Framework ENISA s Information Assurance Framework [ENI09] derives a set of assurance criteria for: the assessment of the risk of adopting cloud technologies, compared to various distinct cloud offerings, business and management process analysis and system policies. The framework is interesting only in terms of the risk analysis for adopting cloud services. In our case this would be adopting critical infrastructure services, otherwise it cannot support the more comprehensive analysis that we require National Security Agency Information Assurance Directorate National Security Agency Information Assurance Directorate [NSA10] provides an exhaustive assessment of the maturity and suitability of relevant IA technologies for meeting information assurance required capabilities. The directorate highlights four main cornerstones: Assured Information Sharing, Highly Available Enterprise, Assured Enterprise Management and Control and Cyber Situational Awareness and Network Defense. The cornerstones are mapped to Information Assurance System Enablers (i.e. Identification & Authentication, Policy Based Access Control, Protection of User Information, Dynamic Policy Management, Assured Resource Allocation, Network Defense & Situational Awareness and Management of IA Mechanisms & Assets) for a more convenient analysis and organization. The IA directorate advocates methodologies and best practices that should be adopted in order to achieve the assurance IA Components. A fine granulation is achieved through components and system enablers that are combined with Information Assurance cornerstones. The IA system enablers are mapped to sets of technology categories and mechanism, therefore regardless of the ability to wide and comprehensive application, the directorate is still repelling to changes. Information Assurance Directorate addresses the problem of critical infrastructures in the scope of its work, but unfortunately without addressing the issues (e.g. locality issues which are also covered with our evaluation) relevant to hosting it on top of cloud infrastructures Handbook for Information Assurance Security Policy This handbook [oe05] specifies information assurance security policies that complied with US federal laws and regulations. The primary focus of this document are policies and guidelines that supports the IA Security Program in protecting the confidentiality, integrity, and availability of the Department's systems and information life cycle. Additionally, the handbook is reinforced through a series of standards, directives, and other procedures documents that address specific aspects of the IA Security Policy. The handbook advocates a set of management, operational and technical controls that undergo various guidelines and standards from the Office of Management and Budget, National Institute of Standards and Technology, General Services Administration and the Office of Personnel Management. Therefore it does not meet our objectives for supporting dynamic and flexible systems, continuous assurance, critical infrastructures in cloud environments or geolocality issues in distributed environments. Deliverable 5.2 Page 8 of 60

9 Department of Defense Directives and Information assurance integrated in Department of Defense (DoD) Directives and [DoD05, DoD03] specify a set of requirements that should be identified and included in the design, acquisition, installation, upgrade, or replacement of any information system within the DoD. The directive is a pointer towards maintaining an appropriate level of confidentiality, integrity, authentication, non-repudiation, and availability. Furthermore, the Directive efficiently utilizes a defense-indepth approach that integrates the capabilities of personnel, operations, and technology. Both directives built the DoD s ICT systems, and therefore address information assurance concerns that are only related to DoD s systems, which makes them less applicable to a broader usage Deputy Assistant Secretary of Defense for Cyber, Identity, and Information Assurance Strategy This document [od09] derives strategies for enabling secure mission-driven access to information and services, anticipate and prevent successful attacks on data and networks, and to prepare for and operate through cyber degradation or attack. The focus of this work is to establish a small set of strategic activities for maintaining and insuring information assurance, which unfortunately covers only a minor part of our objectives regarding assurance Information Assurance Governance Framework The Information Assurance Governance Framework [CSI04] is focused on deriving a functional and managerial hierarchy for information assurance, risk management procedures and guidelines, and to identify mechanisms, procedures and best practices for facilitating information assurance. Furthermore the framework facilitates management and risk confidence of stakeholders. Therefore, this framework is oriented to business aspects rather than technical aspects such as we are addressing as the priority of our work Common Criteria The Common Criteria for Information Technology Security Evaluation framework 1 [CC12] is a well-known approach to apply rigorous engineering methods and processes to the design and development of security and critical IT systems. Common Criteria (CC) provides the process of specification, implementation, and evaluation of security-critical, high-assurance systems in a rigorous and standardized manner. The key concept of CC is that by testing a security product against defined security properties of the product, it can be determined with high confidence if the product can actually meet its claims. In a CC evaluation process, a Target Of Evaluation (TOE) is the product or system under evaluation. A user or a user community identifies common security requirements for a class of devices or systems such as access control devices and systems or key management systems in the Protection Profile (PP) document. A Security Target (ST) document contains the IT security requirements of the TOE and specifies the functional and assurance measures offered by the TOE to meet these requirements. The effort of the evaluation process is ranked numerically from one to seven in Evaluation Assurance Levels (EAL). CC provides not only a benchmark for security " due diligence" checking, but also assurance on the design, development, deployment, and life-cycle handling of security-critical systems. CC can significantly increase the security of a software/hardware system as well as 1 Common Criteria, Deliverable 5.2 Page 9 of 60

10 the confidence of the end-user of the system by emphasizing the importance of good and comprehensive documentation during the system design and development phase. Through this the system development team has security as its main objective from the very beginning. There is also increased awareness related to security problems throughout the system's design and development phases. Regardless of the rich set of features facilitated by the framework, it still does not support the aggregation of different assurance levels for individual components. Neither does it cover the systems hosted in Cloud, or addresses continuous assurance. Therefore this has to be resolved in order to overcome the problems mentioned in the introduction section of this deliverable. However, the approach of Common Criteria offers a solid foundation for building components based assurance framework for critical infrastructures in the Cloud ecosystem Cloud Trust Protocol The Cloud Trust Protocol (CTP) [CSA11] is a mechanism which offers cloud users the opportunity request and acquire information about transparency with respect to cloud service providers. The primary purpose of the CTP and the elements of transparency is to generate evidence-based confidence that everything that is claimed to be happening in the cloud is indeed happening as described. The CTP is an application of the definition of digital trust, assured by such evidence, cloud consumers can be more confident in bringing more sensitive and valuable business functions to the cloud, and reap even larger pay-offs. With the CTP cloud consumers are provided with a way to find out important pieces of information concerning the compliance, security, privacy, integrity, and operational security history of service elements being performed "in the cloud". These important pieces of information are known as the "elements of transparency", and they deliver evidence about essential security configuration and operational characteristics for systems deployed in the cloud. The elements of transparency empower the cloud consumer with the right information to make the right choices about what processing and data to put in the cloud or leave in the cloud, and to decide which cloud is best suited to satisfy processing needs. This is the nature of digital trust, and reinforces again reclaimed transparency is so essential to an enterprise value creation. Information transparency is at the root of digital trust, and thus the source of value capture and pay-off. The Cloud Trust Protocol facilitates data acquisition over distinct cloud providers but is currently mainly focusing on high level properties. We are considering aspects of it via the work with our liaison project Cumulus (see next section) Projects Cumulus The CUMULUS project addresses Cloud certificates. This is in line with the European Commission which identified cloud certification as an enabling technology for building trust for end users through the deployment of standards and certification schemes relevant to cloud solutions. Cloud certification was included in the ten key recommendations and actions for a cloud strategy in Europe [CUM12].The project develops an integrated framework of models, processes and tools supporting the certification of security properties of infrastructure (IaaS), platform (PaaS) and software application layer (SaaS) services in clouds. The framework will bring service users, service providers and cloud suppliers to work together with certification authorities in order to ensure the security certificate validity in the ever-changing cloud envi- Deliverable 5.2 Page 10 of 60

11 ronment. The project relies on multiple types of evidence regarding security, including service testing and monitoring data and trusted computing proofs, and is based on models for hybrid, incremental and multi-layer security certification. To ensure large-scale industrial applicability, this framework will be evaluated in cloud application scenarios from key industrial domains, namely smart cities and ehealth services and applications. Therefore, the certification model is an attractive solution for handling security parameters that have to be met inside of a system. However, at the moment the approach addresses only single level certification within its scope. Thus, without the aggregation of the levels, it addresses the same core problem of meeting security requirements. As the high level goals of SECCRIT and CUMULUS are convergent, we have set up a liaison which included a researcher exchange. This resulted in a joint publication for IEEE CloudCom 2014 [HTL + 14]) A4Cloud The Cloud Accountability Project (or A4Cloud for short) focuses on the accountability for cloud and other future internet services as the most critical prerequisite for effective governance and control of corporate and private data processed by cloud-based IT services. The research being conducted in the project aims to increase trust in cloud computing by devising methods and tools, through which cloud stakeholders can be made accountable for the privacy and confidentiality of information held in the cloud. These methods and tools combine risk analysis, policy enforcement, monitoring and compliance auditing. They contribute to the governance of cloud activities, providing transparency and assisting legal, regulatory and socio-economic policy enforcement. [A4C13]In [FKP14, Pea11], as a part of the A4Cloud project, authors comprehensively address accountability with respect to governance. A4Cloud project addresses assurance indirectly under the scope of accountability within respect to the data governance. The comprehensive approach conducted to ensure the accountability correlates with our scope and goals, the difference is that we base our work on hosting critical infrastructures on top of the cloud stack MYSEA The Monterey Security Architecture [INS + 09](MYSEA) 2 is a research project to build a robust enterprise-level architecture that provides multi-domain authentication and security policy enforcement. The MYSEA cloud consists of high-assurance servers and authentication components for security services. The high assurance of MYSEA cloud is built on a trusted server (i.e., an EAL5-augmented trusted platform) and authentication component (i.e., an EAL7 Least Privilege Separation Kernel). Originally aiming at composing secure distributed systems using commercial off-the-shelf components, some of the results from the MYSEA project might also be applicable to the cloud computing environments. Regarding the topic of this deliverable, MYSEA only consists of a few components evaluated with a certain assurance level (trusted server and authentication component). There is no necessity of aggregating different assurance levels of different components. An advantage of this architecture is that clients respectively cloud service users, also are considered due to security reasons. In the case of a given assurance level framework, there is the gap of what is the right treatment of an unprotected cloud service user which wants to connect to the service. 2 Monterey Security Architecture (MYSEA), Centres for Information Systems Security Studies and Research at Naval Postgraduate School, U.S., Deliverable 5.2 Page 11 of 60

12 2.1.3 Challenges and drawbacks in respect to Critical Infrastructures We present here a summary of our state-of-the-art evaluation of approaches, methodologies, procedures, guidelines and related projects regarding system and information assurance of critical infrastructures hosted on top of Cloud ecosystems. The Cloud ecosystems, as anticipated, can offer full support to scale critical applications (e.g. hospital systems and smart grid systems). Unfortunately, organizations refuse to outsource their resources, regardless if critical or not, without sufficient guarantees that a proper set of actions and measures are in place to provide information and system assurance. The approaches such as mentioned in the work [Abb11] support scalable critical applications over the Cloud infrastructure by providing assurance to cloud users related to the trustworthiness of service delivery in cloud environments, known as operational trust. Particular focus is placed on analysing the most important properties (adaptability, scalability, resilience, availability and reliability) within a cloud, which enable the assessments of the operational trustworthiness or effectiveness of a cloud provider for delivering these services. The assessment of operational trust enables cloud service users, auditors, collaborating cloud providers, and others to improve the decision making and quantifying security properties in terms of levels in a cloud providers. Additionally in [Kai10] authors recommend a trust-overlay network over multiple data centers to implement a reputation system for establishing trust between service providers and data owners. In order to offer additional layer of security and trustworthiness data colouring and software watermarking techniques protect shared data objects and massively distributed software modules. These techniques safeguard multi-way authentication, enable single sign-on in the cloud, and tighten access control for sensitive data in both public and private clouds. We provide some details on our finding in the following and an overview in Table 1. Primarily, we focused on inquiring into and evaluating the work that covers the issues related to Critical Infrastructures and assurance. Although critical infrastructures are a specific and broad domain, additionally hosting them on top of Cloud infrastructure extends their perimeter and improves the performance. However it also raises new challenges related to security, privacy, availability, verifiability, etc. that we observer under the term of assurance. The National Security Agency (NSA) in the Information Assurance Directorate [NSA10] and Department of Education (DoE) in the Handbook for Information Assurance Security Policy [oe05] consider in the scope of their work general assurance requirements related to critical infrastructures. One of our main points of interest is also related to the work done as a part of the SECCRIT project is to investigate locality challenges and issues, therefore we include geolocality concerns (e.g. legislative issues created by crossing administrative and regional when migrating parts of the infrastructure). Geo-locality has been addressed by several large organizations, such as the National Security Agency, ENISA, Department of Defense, Department of Education, and A4Cloud research project. Work from [ENI09, oe05, DoD03, CC12, CSA11, A4C13, INS + 09] referred to the geo-locality as as an obligatory part of a federal or local law, whereby in our case we would like to consider it as cross domain (geographical, federal, regional, administrative) issue required for assessing overall assurance. Also in our interest is the observation perspective of a system, where we wanted to investigate if the system was observed from a holistic or a homogeneous perspective. The majority of the work that was evaluated [COB07, ITA13, ENI09, NSA10, oe05, DoD05, DoD03, od09, INS + 09, A4C13, CUM12, CC12, INS + 09] derived their work in a holistic manner, with minority of approaches [ENI09, CC12, A4C13, CUM12, INS + 09] focusing on observing systems in a heterogeneous manner. Furthermore we wanted to see how a particular state-of-the-art work observes the properties of a system over time. Therefore, we focused on evaluating if state- Deliverable 5.2 Page 12 of 60

13 Table 1: Evaluation of state of the art approaches (e.g. frameworks, guidelines, standards and related projects) which address assurance outcomes. The majority lacks support for Cloud environments and a way to continuously evaluate assurance Frameworks/Guidelines/Standards Projects IT Assurance Guide Information Technology Assurance Framework Cloud Computing Information Assurance Framework Information Assurance Directorate Handbook for Information Assurance Security Policy Directives and Deputy Assistant Secretary of Defense for Cyber, Identity, and Information Assurance Strategy Information Assurance Governance Framework Common Criteria for Information Technology Security Evaluation Framework Cloud Trust Protocol Certification infrastructure for multi-layer cloud services project A4Cloud project The Monterey Security Architecture Assurance in the Cloud Geo-locality Homogeneous system Heterogeneous system Static infrastructure assessment Dynamic infrastructure assessment Data/Information assurance System/Service assurance Continuous assurance Information assurance Definition Aggregation of assurance-infos of-the-art work is capable of confronting dynamic system changes such as component, class, modules, vendor, etc. that can change their functionalities and characteristics. In particular, the work of [COB07, ITA13, ENI09, NSA10, oe05, od09, CC12, A4C13, CUM12] considers only a static system observation, whereby the work of [CC12, COB07, A4C13, CUM12] due to their flexibility in the approaches are able to describe a system through components and deal with dynamic changes of a system. The next point of our evaluation is observed within respect to the definition of assurance and its elements (data and service assurance). The majority of the evaluated state-of-the-art work [COB07, ENI09, NSA10, oe05, DoD05, DoD03, od09, CSI04, CC12, A4C13, INS + 09] distinguishes the work in both system and information assurance, whereby the remaining work [ITA13, CSA11, CUM12] did not address this issue at all. Despite the fact that CUMULUS [CUM12] does not directly address the assurance, the major benefit of their approach is the ability to continuously deliver assurance through the certificates that they deliver only on an individual level. Furthermore we evaluate who defines assurance to avoid ambiguity of the term being used in a general manner. Unfortunately, only a minority of the evaluated work [ITA13, DoD05, DoD03, od09, CSI04, CC12, A4C13] formalised assurance in form of a definition with respect to particular objectives. As the last point of our evaluation we assessed the capability of the state-of-the-art approaches to aggregate the assurance of individual components for evaluating a system as a whole. Only the approaches [CC12, CSA11, A4C13, CUM12] have addressed the problem of information aggregation to holistically observe a given system. Deliverable 5.2 Page 13 of 60

14 2.2 State of the art open source monitoring tools Monitoring Tools We evaluated state of the art open source monitoring solutions to investigate their potential applicability to support our assurance methodology. Therefore, we analysed whether each individual monitoring tool is capable of addressing assurance related issues, such as dynamic, cross layer interaction, continuous, policy based or distributed information acquisition (monitoring) Nagios Nagios [Ryd13, Tur06] is a well-known and widely used open source monitoring solution capable of monitoring all devices using the TCP/IP protocol suite, within interconnected network such as network and infrastructure devices. This particular monitoring solution is capable of acquiring data from distinct remotely accessible infrastructure devices and delivering them to the central aggregation module (i.e., server used for data acquisition and further data analysis.). Nagios provides a complete solution for monitoring cloud based environments including a variety of servers and operating systems especially adopted physical and virtual OS. Moreover, Nagios supports the complete Amazon cloud infrastructure (Amazon Monitoring, AWS Monitoring, EC2 Monitoring and S3 Monitoring). Unfortunately, Nagios does not support device auto-discovery which in large scale dynamic environments can be a significant drawback. Also like a lot open-source driven solutions Nagios is based on complex text based configuration files which makes it challenging to administrate. The user interface is not interactive and does not track history of performance records. Moreover, Nagios does not have the ability to distinguish devices per types ( e.g. servers, routers, or switches). Therefore, Nagios is not capable of addressing challenges such as continuous or cross layered monitoring, defining policy or interval based monitoring in multi-tenant environments requires additional adoption of his plugins DARGOS The Distributed Architecture for Resource management and monitoring in clouds (DARGOS) [JJJ + 13b, JJJ + 13a] is a scalable and data-centric cloud based monitoring solution for disseminating monitoring information/artefacts in large-scale federated and multitenant Cloud environments. DARGOS is a highly efficient and accurate solution for monitoring or collecting data on infrastructure and tenant resources in the Cloud. In addition, DARGOS is also a flexible solution that allows to easily define new monitoring metrics, without degrading the performance. In [JJJ + 13a] the authors demonstrate how the proposed monitoring architecture and related tools could be integrated into a real Cloud deployment solution such as the OpenStack platform. DARGOS does not offer the ability to the cloud customer to customize and configure the resources and services to be monitored. Furthermore, due to the early development the set of metrics monitored by Dargos are unfortunately really limited. Unfortunately, DRAGOS is also not designed to scale because of their design model to send all data to a central server which represents a clear bottleneck Sensu Sensu[Arn13, Van14] is an open source monitoring solution also known as "Monitoring Router", written in Ruby and flexibly configured using a JSON notation. The architecture of Sensu is message-oriented using RabbitMQ and JSON payloads with a user friendly user interface solution. Sensu uses RabbitMQ to establish client server communication, Deliverable 5.2 Page 14 of 60

15 therefore it is compatible with message oriented architectures. The main benefit of this tools is the ability to flexibly customise its acquisition modules and flexibly scale across infrastructures Hyperic-HQ Hyperic HQ [McG10a] is an open source enterprise monitoring system. In contrast to other open source systems Hyperic-HQ is easy to configure and has automatic auto-discovery of resources for both the virtual and physical infrastructures. Moreover, Hyperic HQ is focused on application layer performance metrics by offering the ability to collect application-specific performance metrics automatically using a system of logical defaults. The tool has five essential components, HQ-agents installed in each monitored machine to gather information or metrics and to administer all servers; a HQ-server that receives data from HQagents and stores it in HQ-database; HQ-portal a graphical user interface and HQ-web services API that provides access to all HQ-servers. The main drawback of this tool is the lack of multi-tenant support Munin Munin [McG10b] is an open-source monitoring solution, written in Perl, designed to monitor infrastructure, network devices, and services. Unfortunately, Munin does not offer much flexibility when accessing monitored hosts and configuring the monitored network. Although Munin offers the ability to run various customisable scripts it only offers a fixed interval scan rate where these scripts could be initiated. One of the major drawbacks of Munin is its text file configuration model which can be quite complex MonPaas MonPaaS [ACGA14] is a customisable distributed monitoring solution designed for large scale deployments, therefore making it suitable for deployment in Cloud like environments. Furthermore, MonPaaS successfully integrated Nagios within the OpenStack environment, and provides automatic detection of monitored artefacts. However, MonPaaS is focused only on monitoring in the tenant and physical infrastructure. Cloud customers are also able to access the monitoring information of the status of the infrastructure, i.e. multi-tenancy support. The information that is provided to the cloud customer significantly different from the information that is provided to the cloud provider. Unfortunately this monitoring solution does not cover all cloud stack layers and therefore does not provide a complete analysis of the Cloud environment PCMONS The Private Cloud MONitoring [DCUW11] solution is a monitoring system designed for private cloud infrastructure monitoring. The solution is a compound of infrastructure layer, integration layer and view layer divided into eight components (Node information gatherer, Cluster Data Integrator, Monitoring Data integrator, VM Monitor, Configuration Generator, Monitoring Tool Server, Monitoring Tool Server, User Interface and Database). Main goal of PCMONS is the extensibility of its services Zabbix Zabbix [Vla01] is an enterprise open source monitoring tool focused on network infrastructure monitoring. It is based on an agent-less monitoring concept without connecting to the host and therefore reducing the impact on the performance. Furthermore, Zabbix provides distributed monitoring in real time with centralized Web administration. It offers an overview of all hosts inside the network from a single point of entry. Performance monitors include everything from host memory, processor, and swap space usage to free disk on all mounted partitions, running processes, disk read/write operations, and more. However, Deliverable 5.2 Page 15 of 60

16 according to [Mur08] the tolls are limited when it comes to automatic discovery of monitoring objects Zenoss Zenoss [Gro05, Bad08] is an open source IT monitoring software that offers an overview of the entire IT infrastructure, from physical infrastructure to the services running through its rich feature set (e.g. automatic discovery, availability monitoring, performance analysis, sophisticated alerting, etc.) Furthermore, Zenoss offers extensibility and flexible customization of monitoring environments via its additions such as ZenPack. Unfortunately, Zenoss does not support different devices (e.g. HP OpenView, Microsoft Exchange or SQL Server) but it can assure these with commercial tool Cacti Cacti is an open source solution for monitoring a complete network based on RRDTool's (round-robin database tool) for interactive assessment of data like network bandwidth, temperature or CPU load. The tool is easy to install and it offers a distributed monitoring features in multi-tenant environments. Furthermore, its capabilities are easily extended and customised to align with infrastructure monitoring requirements Summary of monitoring tools functionalities We performed a survey analysis of open source cloud-based monitoring tools to investigate how they confront monitoring challenges in clouds with respect to our assurance methodology. Therefore, we focus on monitoring challenges such as cross layer monitoring, continuous monitoring, policy based monitoring, interval based monitoring, event based monitoring, distributed monitoring, multi-tenant monitoring, scalability, extensibility or customizability. For cross layer monitoring our analysis shows that most of the tools such as [JJJ + 13a, Van14, ACGA14, DCUW11, Bad08, KL09] support this feature and offer the capability to aggregate the data across distinct layers. Further point of interest was to see whether the tools have the ability to integrate custom based policies of an individual provider or standard. However, our result show that there is no open source tool capable of performing this action. One of the important aspects for us was to investigate whether the tools are more focused on interval based or event based monitoring. DARGOS [JJJ + 13a] was the only tool that provides the support both features while the remaining tools are split between interval based [McG10a, McG10b, ACGA14, DCUW11, KL09] and event based monitoring [Ryd13, Tur06, Van14, Vla01, Bad08]. Unfortunately, only a minority of the evaluated tools [JJJ + 13a, ACGA14, DCUW11, KL09] provide some support for multi-tenant monitoring. One of the important objectives of our evaluation was the scalability of monitoring tools, which comes highly important in context of cloud computing where analysing large scale data sets is often a case. However, scalability was supported only by a minority of the evaluated tools [Van14, McG10a, ACGA14, Vla01, Bad08]. Further objective of evaluation was extensibility of a monitoring tool, which shows the capability of a tool to extend beyond its perimeter. The extensibility was supported from the majority of the tools that we analysed [Ryd13, Tur06, JJJ + 13a, Van14, McG10a, DCUW11, ACGA14, Vla01, KL09]. Fortunate a positive aspect for our approach is the customizability that most of the tools provide [Ryd13, Tur06, JJJ + 13a, Van14, McG10a, DCUW11, ACGA14, Vla01, KL09, Bad08, McG10b]. Customizability is important feature that offer the ability to fine tune our requirements in to the existing solution to realise a compact evidence gathering mechanism as envisioned in [FPT13]. The outcome of our survey, clearly indicates that there is no single existing solution that supports all of our requirements regarding assurance related information acquisition in Cloud environments. Therefore based on this survey we conclude that a mechanisms is required which Deliverable 5.2 Page 16 of 60

17 allows to combine existing tools, we propose this in [FPT13]. Please also note that the analysis of monitoring tools is being extended with concrete security properties used for our methodology evaluation in section Security Requirements for Critical Infrastructures in the Cloud Assessing a set of mechanisms to address especially Cloud related security issues [BLS + 13] and aspects is quite cumbersome and often not easy to achieve. Therefore a systematic approach such as proposed by [CC12, CUM12], for handling such security related challenges is required. However, despite the comprehensiveness of the referenced approach its authors have to clarify the abstraction for deriving their methodologies or concepts (i.e. they have to justify the basis for their decisions to build such concepts). Therefore, we decided to support our Assurance assessment methodology with a survey, which is current work carried out for another SECCRIT task (3.3. on Process-oriented security guideline). A preliminary partial snapshot of the results was used together with the related work above to support the identification of security classes (confidentiality, integrity, availability) and security properties used for this work. Our survey was supported by 111 international participants coming from both academia and industry (including critical infrastructure providers). The survey was conducted via questionnaires distributed during events at which we disseminated SECCRIT outputs, those included: Building Trust in Cloud 3, CMG-AE - event CMG-AE Tagung IT security in Critical Infrastructures and distributed systems 4, Big Data Security 5 and online networking distribution 6. 3 BRZ, Building Trust in Cloud, 4 Computer Measurement Group - Austria & Eastern Europe (CMG-AE), IT Sicherheit in kritischen Infrastrukturen + vernetzten Systemen, - kritischen-infrastrukturen-a-vernetzten-systemenq 5 Vienna University of Economy, BIG-DATA-SICHERHEIT im vernetzten Verkehr! Impuls- und Dialogveranstaltung 6 Online survey tool, oobawvcsz516lei555460&refer Deliverable 5.2 Page 17 of 60

18 3 Catalogue of security properties This section outlines one of the core components supporting the Assurance Assessment Framework (AAF), the Assurance Catalogue. The Assurance Catalogue details each individual security property used to perform the assurance assessment process for an individual security domain. Therefore the properties are clustered in the security domains, which we formally refer to as Assurance Classes. A security property is based on high-level definitions in existing standards - made measurable. The conceptual approach, i.e. the catalogue s design is generally applicable to our methodology. However, the here explained security properties are only a representative set which was derived with the industrial partners of the SECCRIT project and based on existing work e.g. SECCRIT Deliverable D3.1 [BLS + 13] and supported by the before mentioned survey. This modest set enumerates 12 security properties, associated with security classes: confidentiality, integrity and availability. We envisage an individual security property as a measure for whether certain security mechanisms within a considered component of the cloud service are fulfilled, or not. Examples include e.g. password rotation, strong passwords. They are not only categorised in security classes but each one is individually analysed whether it can be measured at the various levels (Service, Tenant, or Infrastructure). Hence for each security property in our catalogue we provide the following information: 1. assurance class: Confidentiality, Integrity or Availability (the properties are presented clustered per class) 2. the description of individual assurance classes with respect to the traditional computer security definitions [Bis04, SB07]. 3. the high-level definition of a security properties based on standards such as e.g. ISO the definition of a monitoring artefact that defines how the particular security property can be monitored, based on the official releases of the monitoring tools mentioned in our state of the art discussion (this does not not include features of unofficial open source plug-ins for the individual monitoring tools) 5. a short description of an implementation concept for monitoring the individual security property - in case none of the monitoring tools (the official releases) supports monitoring the specific property, we sketch how this is technically possible and refer, wherever applicable to the before mentioned unofficial modules of the individual monitoring tools Please note: were the documentation for the intended use of a specific monitoring tool was not sufficient, or where we needed to experiment with system configurations regarding customised scripts, we have evaluated this with our Open-Stack test-bed. The setup of our test-bed is Linux based and consists of a firewall, two Open-Stack controller nodes and two compute nodes. We are using the Open-Stack release Ice-House, which was the latest one at the time conducting this work. An extension of our work is planned for the demonstrator phase of the SECCRIT project. 3.1 Confidentiality For the scope of the AAF we slightly extend and abstract confidentiality as an assurance class aligned with the definitions from [Bis04, SB07]. Thus, we define confidentiality as concealment of information or resources focused on preserving authorized restrictions and disclosure, including means for protecting personal privacy and proprietary information. Furthermore, under Deliverable 5.2 Page 18 of 60

19 the assurance class confidentiality we identified and enumerated set of measurable security properties, in the following, which we will use further for our assurance assessment methodology. As mentioned before this is not a finite set of properties, which could easily be extended, but rather a working set that supports our assurance framework evaluation Concurrent Session Control Security property definition: A property that supports confidentiality by restricting the maximum number of concurrent sessions per a system account, by account type, or by both. Def. Source: NIST Special Publication mapping: AC-10 [RKJ + 05] Catalog of Control Systems Security mapping: [Sec11] Monitoring artefact definition: This property can be monitored by checking if tools that capture concurrent session information and control them, are installed on the component of consideration. Munin 7 has the ability to monitor and control concurrent sessions which are actively running on service layer. Implementation possibility: For assuring concurrent session control in infrastructure and tenant layer a script can be developed which checks sshd_config 8 or pam_limits module 9 configuration in the /etc directory Strong passwords Security property definition: A property that supports confidentiality by assuring that a certain degree of complexity is required for passwords. Def. Source: ISO / IEC mapping: [IS05] NIST Special Publication mapping: IA-5[RKJ + 05] Catalog of Control Systems Security mapping: [Sec11] Monitoring artefact definition: This property can be monitored by checking whether tools or services that enforce complex passwords are installed on the considered entity and via checking if those means are in use Deliverable 5.2 Page 19 of 60

20 Implementation possibility: Strong passwords monitoring can be implemented by performing checks on the PAM module. PAM (Pluggable Authentication Module) 10 is a Linux module to verify user s identity, which requires a minimum length of passwords and password rotation Encryption Security property definition: A property that supports confidentiality by assuring that access to the data that is encrypted remains restricted to those who are not in possession in the proper encryption/decryption key pair. Def. Source: ISO / IEC mapping: 12.3 [IS05] Monitoring artefact definition: This property can be monitored by checking if block device encryption and secure communication protocols are present and there is evidence that those measures are active at the particular entity which is monitored/evaluated. Implementation possibility: For assuring encryption in infrastructure and tenant layer a script can be developed which checks if dm-crypt module 11, which is a kernel-level encryption mechanism, is installed. This module is used to encrypt Linux system content such as separate partitions, devices and file systems. For assuring encryption in all three layers one must also create a script that checks if e.g. the https protocol is used instead of http for communication Secure Data Deletion Security property definition: A property that supports confidentiality by assuring that information, which was stored on some allocated storage space or blocks, after no longer being needed is electronically wiped (i.e. irreversibly deleted). Def. Source: NIST Special Publication mapping: 2.4 [KSSL06] Monitoring artefact definition: This can be measured by checking if tools that support data deletion are installed on the entity of consideration and that those means are in use. Implementation possibility: For assuring secure data deletion at each individual layer (infrastructure, tenant and service) a script can be developed which checks if secure data deletion tools are installed (e.g. shred, wipe, DBAN etc) Deliverable 5.2 Page 20 of 60

21 3.2 Integrity Like with the assurance class confidentiality, in the scope of the AAF we abstract integrity and align it as an assurance class with respect to the definitions from [Bis04, SB07]. Thus, we define integrity as assurance that consistency of data or services has been maintained or begin changed from authorised party. Furthermore, the aspect of a system integrity assures that a system performs its intended function in an unimpaired manner, free from deliberate or inadvertent unauthorized manipulation. We also enumerate and identify under the assurance class integrity a set of measurable security properties, in the following which we will use further in our assurance assessment methodology. As with confidentiality this set is not a finite set of properties, it can easily be extended, and it will be used as a working set that supports our assurance framework evaluation Data Error Correction Security property definition: A property that supports integrity by assuring that (up to a certain degree) data is resilient to errors (i.e. data or information can be recovered from errors that potentially occurred during transmission by malicious or non-malicious nature). Def. Source: Ensuring Data Integrity in Storage: Techniques and Applications [SWZ05] Monitoring artefact definition: This can be measured by checking if the techniques that support data error correction (RAID5, ECC, FEC etc) are installed on the entity of consideration and that those means are in use. Implementation possibility: For assuring data error correction on infrastructure and tenant layer we can customize and extend the existing Nagios plugin, check_raid 12 or Zabbix plugin zabbix_mdraid 13. Service layer can be monitored by developing a script which checks if ECC (Error Correction Code) or FEC (Forward Error Correction) tools are installed on the component of consideration Service Behavior Anomaly Detection Security property definition: A property that supports integrity by assuring that there are means present for supporting detection of deviation from standard security behavior at the component of consideration. Def. Source: Academic paper: Anomaly detection: A survey [CBK09] Monitoring artefact definition: This artefact is monitored as a deviation from standard behavior of a component, there are services present that support anomaly detection at a particular entity and that these means are in use RAID-Controllers/check_raid/details 13 Deliverable 5.2 Page 21 of 60

22 Implementation possibility: We can implement a script in all three layers that will investigate whether there are anomaly detection tools monitoring a particular service or a component required for such a service - based on the building blocks sketched in the SECCRIT deliverable D4.2 [Con14a] Information (Data) Consistency Security property definition: A property that supports integrity by assuring that at any point of time transmitted or stored information is resilient to alteration(i.e. information transmission resistant to alteration by applying mechanisms such as CRC or HASH). Def. Source: ISO / IEC mapping: 12.2 [IS05] Monitoring artefact definition: This can be monitored by checking if tools that support integrity ( mirroring, parity checks, checksumming, CRC(Cyclic Redundancy Check or Hash) are present on the component of consideration and there are evidence that this property has been applied at a particular entity that is monitored/evaluated. For infrastructure and tenant layer Zabbix [Olu10] can perform MD5 checksumming integrity technique. Implementation possibility: Assuring this property on service level is possible by customizing or extending based on our needs the existing sensu plugin mysql_replication_status.rb Data Alteration Prevention Security property definition: A property that supports integrity by assuring that there are services present which can prevent any kind of unauthorized modification of the data. Def. Source: ISO / IEC mapping: 12.2, 12.3 [IS05] Monitoring artefact definition: We can monitor this property by identifying whether there are mechanisms like encryption, hashes or digital signatures applied on a particular component. Implementation possibility: Assuring this property on the service layer is possible by customising the unofficial existing Nagios plugin check_wp.sh 15. For assuring encryption in the infrastructure and tenant layer a script can be developed which checks if the dm-crypt module 16 is installed mysql-replication-status.rb Deliverable 5.2 Page 22 of 60

23 3.3 Availability As with confidentiality and integrity, in the scope of the AAF we abstract Availability and align it as an assurance class with respect to the definitions from [Bis04, SB07]. Thus, we define availability as assurance that the data or service is continuously accessible without any disruptions. We enumerate and identify under the assurance class availability, measurable security properties, in the following which we will used further for our assurance assessment methodology. As we as with confidentiality or integrity this set is not a finite set of properties, it can easily be extended, and it will be used as a working set that supports our assurance framework evaluation Load Balancing Security property definition: A property that at the same time offers balancing of workloads across distinct computational nodes and failure resistance in case one of the nodes becomes unavailable or disrupted. Def. Source: OpenStack Operation Guide [FFG + 14] Monitoring artefact definition: This can be monitored by assuring that there are services present that can perform load balancing techniques and there is evidence that such means are in use for the component under consideration. Implementation possibility: To assure load balancing on infrastructure, tenant and service layer a script should check if load balancing techniques, such as DNS Round-Robin, HAProxy software load balancing etc., are installed and enabled Horizontal Resource Scaling Security property definition: A property that supports availability by assuring that a particular service of a system could be spawned across the additional physical or virtual nodes. In addition, horizontal scaling is also not limited since we can add additional nodes to the resources poll used for scaling out our services. Def. Source: OpenStack Operation Guide [FFG + 14] Monitoring artefact definition: Under the assumption that adding extra machines is possible, this property can be monitored by e.g. checking if data replication techniques are present on the component of consideration. All evaluated monitoring tools in Table 14 have the ability to auto-discover dynamic changes on infrastructure and tenant layer except Nagios and Cacti. Deliverable 5.2 Page 23 of 60

24 3.3.3 Live Migration Security property definition: A property that supports availability by assuring that services could be flexibly migrated without significant downtime. Def. Source: OpenStack Operation Guide [FFG + 14] Monitoring artefact definition: This property can be monitored by assuring that there are services such as hypervisor libvirt virtualization API present. Implementation possibility: For assuring live migration in infrastructure, tenant and service layer can be developed a script which checks if libvirt 17 live migration functionality is enabled in the configuration file Live Backup Security property definition: A property that supports availability by assuring that a live backup of a particular entity could be conducted and therefore service downtime could be avoided. Def. Source: ISO / IEC mapping: [IS05] NIST Special Publication mapping: CP-6, CP-10 [RKJ + 05] Catalog of Control Systems Security mapping: [Sec11] Monitoring artefact definition: This property can be monitored by assuring there are services that support backup (rsync, vranger) present on the entity of consideration and there is evidence that those means are in use. Implementation possibility: For assuring live backup on tenant and service layer we can customize the existing unofficial Nagios plugin check_vranger_jobstatus 18. To assure live backup on infrastructure layer can be developed a script which checks if rsync 19 is installed on the component of consideration. Rsync is a protocol for Unix-like systems that provides backups and synchronization of data Deliverable 5.2 Page 24 of 60

25 3.4 Security Properties Compliance with State of the Art Monitoring Tools - a Summary We can summarize that most identified security properties require customized scripts and only a few can be monitored by official releases of existing tools. However, the majority of those customised scripts can be based on existing open source plug-ins for the individual monitoring tools. The aim of the evaluation was to show how each individual monitoring tool, outlined in state of the art discussions supports each one of the properties derived with our SECCRIT demo partners. We have also provided initial ideas how customized scripts can support those measurements if the official software does not support it. We also analyse two outputs of the SECCRIT project on their capabilities to support the monitoring of assurance relevant information: Tools for Audit Trails and Root Cause Analysis (Deliverable 5.1 [Con14c]); and Anomaly Detection Techniques for Cloud Computing (Deliverable 4.1 [Con14b]). We provide a summary of the above information in Table 14 in the appendix. Deliverable 5.2 Page 25 of 60

26 4 Assurance Assessment Framework and Methodologies The widely accepted model of the National Institute of Standards and Technology (NIST) [MG11] depicts the Cloud architecture as a dynamic tree-layered service-provisioning model (infrastructure, platform and software - as a Service layer) capable of scaling services across distinct administrative and legislative domains. However, the common best practice for provisioning and delivering services (as well as the abstraction of those layers and driven technologies) depend on the business objectives of a particular Cloud provider. Hence, the traditional assessment frameworks (e.g. COBIT [COB07] or ISO series) are not eligible, especially when addressing security related concerns in Cloud environments (as we discuss in [HHT + 14]). In addition, when assessing such dynamic and volatile environments we confront challenges such as large scale data analysis on the fly, dynamic infrastructure (virtual) changes or monitoring services. Hence, such challenges require an out of the box solution capable of addressing all of them and being cohesive at the same time. Hence, impact of such monitoring solutions should not degrade the performance of any of running services. Furthermore, as a first step of the cyber-risks that exist in the use case scenario have to be understood alongside the security properties that need to be assessed. Perceptions of risk in the context of hosting critical infrastructure in Cloud environments therefore have to be well understood since they will inevitably influence decisions about the adoption of Clouds or the security controls that will be applied to them. Two important factors that must be taken into consideration for a better understanding of cyber-security risks are: (i) the threats and their likelihood to occur; and (ii) the vulnerabilities and an indication of their severity. A key challenge when understanding the risks associated with Cloud computing is to determine those that are specific to the use of Clouds. In order to comprehend the Cloud-specific risks of our scenario we use the Cloud vulnerability catalogue the SECCRIT project [BLS + 13] has developed, in which we then mapped the Notorious Nine Top threats 2013 from [G + 13]. Further, with the help of the CUMULUS project s security property catalogue [CUM12], we map these vulnerabilities to possible security properties for their assessment. The basis of this catalogue is the identification of a number of security related classes that enable us to focus directly on Cloud-related issues. Thus, a framework capable of comprehending these challenges mentioned above is required. However, for building such comprehensive and flexible framework able to acquire heterogeneous information across the Cloud stack the following objectives have to be considered: cross layer assessment ability to function volatile dynamic environment information acquisition restrictions assessment, quantification and aggregation of different information sets The assessment of services or infrastructure when taking into account different Cloud layers requires a compact solution, capable of embracing all requirements and producing efficient assessment tool. When putting in to a context considering different stakeholders various business and security objectives, a high degree of service complexity, business model, and distinct technologies. Hence, we adopt Common Criteria [CC12] to address assurance in Cloud related environments. However, Common Criteria offers a comprehensive solution for assurance assessment, it lacks support for the production phase, especially when referring to those services that are hosted on top of the Cloud architectures. Taking this and the above-mentioned Deliverable 5.2 Page 26 of 60

27 objectives into account, we use the Common Criteria approach in order to address assurance assessment of complex services hosted in Cloud infrastructures in the context of security. Furthermore, unfortunately the policies of some Cloud providers restrict information gathering across their Cloud stack (for instance a software as a service Cloud provider will hesitate to reveal information about the underlying services being used, in order to mitigate potential attack vectors on its infrastructure). Therefore, it is harder to analyse, indicate or predict security issues in such environments. Thus, we distinguish two main categories: solutions based on open-source Cloud environments (i.e. solutions where we are able to freely acquire necessary information without the approval from the provider) commercial Cloud environments with restricted information access (i.e. public Cloud providers which provide any additional information via the Service Level Agreements (SLA) [WB10, Moh10]). Due to the ability to flexibly acquire information and modify services for provisioning information, this work focuses primarily on open-source Cloud solutions (e.g. OpenStack 20 or CloudStack 21 ). This, however, does not restrict our approach to these environments only, but gives us the opportunity for easy deployment of such environments for testing purposes. Our concept proposes the assessment and aggregation of different information sets (i.e. analysis of a particular entity in the Cloud with respect to a specific set of properties) build upon the abstraction of assurance levels, supported through aggregation policies (i.e. decision making algorithms that cluster the security properties of each class towards the predefined assurance levels), aligned with the methodology proposed by Common Criteria [CC12]. The fundamental concept of our concept lies in the bit-wise/logical conjunction of security properties (SP) represented as bit vectors. We conjunct these bit vectors towards the root (target of the evaluation), by a horizontal and vertical aggregation concept. In addition we provide aggregation policies which additionally enhance our methodology by fine tuning the aggregation towards the root, which we formally refer as Target of Evaluation (ToE),and offering the possibility to derive the overall assurance of each individual component. 4.1 Assurance objectives Despite the fact that the future model for provisioning and delivering services in the Cloud[MG11] is envisioned similarly as delivering public utilities (e.g. water, electricity, gas, and telephony), common best practices differ based on the business objectives of a particular Cloud provider. Moreover, an additional level of complexity arises when addressing different stakeholders, variety of businesses and security objectives, along with a high degree of service complexity, distinct business models or variety of technologies. Furthermore, a major obstacle for migrating services to the Cloud environments, especially those containing highly sensitive data and critical services, is assurance that adequate level of security is achieved or maintained. The assessment of such services, when additionally taking into account different Cloud layers, requires a cohesive solution, capable of systematically addressing and comprehending all requirements, challenges and producing an effective assessment continuously. Moreover, the ability to host various services that divergently exploit Cloud infrastructure result often as a security issue in context of policy regulations. Unfortunately traditional assessment frameworks 20 [OpenStack, 21 CloudStack, Deliverable 5.2 Page 27 of 60

28 (e.g. COBIT, ISO series, Common Criteria etc.), commonly used as best practices, detailed in 2 section, are not fully applicable to address the above mentioned challenges. A well-known advantage of Cloud technologies are services built to scale across the Cloud infrastructure and resources. Consequentially this makes the task of assuring security for such services based on nested components significantly complex. However, due to the nature of CI services characterised through high security requirements, in order to establish our methodology, we had to comprehend variety of complex and unique Cloud security challenges, such as addressed in 22 (e.g. data location, data segregation, recovery, investigative support, long-term viability). Therefore, we summarize the Assurance Methodology for addressing the aforementioned challenges through following objectives: Continuous security assessment Cross layer information acquiring Flexible policy integration Lightweight cohesive monitoring (evidence gathering) Policy based analysis 4.2 Assurance Framework Taking into account the objective mentioned above and the concepts presented in [HHT + 14], we propose a comprehensive and flexible approach for performing assurance assessment, which was recognised from the scientific community [HTL + 14]. The approach is based on a the set of security properties, example set enumerated in Section 3, is used for demonstrating the efficiency of our methodology in our Assurance Framework. However, due to the heavy workload required to for identifying each individual property per class we will derive a reduced set for the time being to demonstrate our methodology and continue to extensively analyse and extend our property set in our ongoing research. Our assessment methodology, in line with [CC12], emphasises the following core assessment entities: Target of Evaluation (ToE), Group of Evaluation (GoE), Component of Evaluation (CoE) and Assurance Profile (AP). These entities follow and extend the concepts of the Common Criteria assessment framework, and therefore offer flexibility, determination of the precise impact of the individual components or group of components, scalability of assessment across different time intervals, and the possibility to highlight individual entities of the system as an independent point of evaluation. The CoE is the smallest individual entity inside of a system that can represent an independent standalone feature (e.g., running service), which we abstract using the term component in our framework. Each individual CoE can therefore also be considered as an independent ToE as well. Moreover, set of individual components grouped together is abstracted in our framework as a Group of Evaluation (GoE). By taking in the account the same principle as with the CoE we can isolate individual GoE as an independent ToE. The compound of individual GoEs and CoEs is defined in our framework using the notion of a Target of Evaluation (ToE). In order to efficiently evaluate a target (i.e., service, system, infrastructure, tenant, etc.), security objectives should be enumerated and comprehended. Detail the correlation between security objectives, assurance classes and properties for a ToE are defined via the Assurance Profile (AP). The 22 D3.1 Methodology for risk assessment and managementhttps:// D3-1-Methodology-for-Risk-Assessment-and-Management.pdf Deliverable 5.2 Page 28 of 60

29 AP is an essential element of our proposed methodology that enumerates security objectives in terms of Assurance Properties and associates them with corresponding Assurance Classes (AC). Furthermore, these security properties define the level of assurance for an individual component, group or even a whole system. In addition, the policies derived in the scope of an Assurance profile define how horizontal and/or vertical aggregation of assurance across the evaluated entity is conducted. Figure 1: General tree model. Hierarchical illustration of services via the general tree model structure. The service or application is defined as a Target of Evaluation (ToE) depicted with the individual Components of Evaluation (CoE), whereby each individual CoE can be associated with N distinct CoEs, referred as Associated Component Set (ACS). The correlation between two individual CoEs is referred to as a Component Dependency, which is a formal compound of Association. Moreover, CoEs are grouped in order to establish assurance of components with respect to specific security classes, these groups are then formally defined as Groups of Evaluation (GoE) Abstraction model In order to illustrate the complete cloud stack (e.g. infrastructure, tenant and service level) we abstracted individual components of the environment and the corresponding relationships between the components via a hierarchical tree structure familiar as a General Tree model[ber98, Sam06]. A general tree G is a finite compound set of nodes such that there is only one designated node R, referred as root of the tree G, where each individual node has only one ancestor (Parent) node, with exception of the root, and multiple successors (Children). Each node of the tree is defined by two properties: Depth and Degree. Depth of the node is the distance of the node from the root node, and Degree of the node is the number of successors for a particular node. Moreover, each general tree can be partitioned in n > 0 disjoint subsets T 0, T 1, T 2...T n 1, where each is a tree whose roots R 0, R 1, R 2...R n 1 are children of the tree G. The subset T i Deliverable 5.2 Page 29 of 60

30 (0 <= i <= n) is a subset of the trees of T. Although we intent to depict our services through a general tree based model, they can be also depicted via the binary tree model, since the general tree model is easily transformed to A binary tree. To demonstrate of our algorithm (2) we will use the general tree model(1). However, we will not address the assessment of binary trees as it exceeds the scope of this work Methodology The first challenges that we had to confront and comprehend when considering the assurance aggregation was how to iterate through each individual object that we are evaluating and regardless of the case end the iteration at the root element. Hence, we decided to use the tree traversal post order method [Val02, Ata98] which iteratively walks through the general tree starting from the leftmost leaf object and iterating through all elements of the tree towards the root element of our evaluated target. Table 2: Assurance level association per class. Set of relevant SPVs clustered per individual AC represented with a hexadecimal vector. The left hand side of the table shows the SPVs, sorted by relevance, and all potential appearance combinations for a particular vector SP V = [SP 4, SP 3, SP 2, SP 1 ]. The right hand side shows for each SPV the binary vector of its associated assurance level. Hexadecimal representation of each particular binary AL vector is illustrated. The initial step of the assessment method defines and details the ToE. This can be either an asset of the Cloud referred to as a service (e.g., a specific service operation, a set of service operations, data managed by the service) or an asset that is required or contributes to the realization of a Cloud service (e.g., a virtual machine). Moreover, each ToE contains a set of attributes such as: (i) security objectives, which are mapped to the related set of security claims and are formally referred to as Security Properties (SP); (ii) attributes that define the type of assurance (e.g. information or system assurance) according to the assurance model presented Deliverable 5.2 Page 30 of 60

31 in [HHT + 14]; (iii) a short description of the ToE; and (iv) the assessment interval. The security objectives are the statements of intent to counter the identified threats by IT measures. Each ToE can be formally defined as ToE = T ={COE i, i N} {GoE i, i N}. This generalized statement presented in Figure 1 can be formulated as ToE = COE A = {COE i, i B, C, D, E, F, G, H, I, J, K, L, M, N }. The group of objects, which we formally refer as Group of Evaluation (GoE) is defined as GoE ={CoEi, i N}, and is a compound set of individual objects that share common properties based on which the assessment is conducted. Considering Figure 1, a GoE can be formulated as compound of objects, e.g. GOE 1 = {COE i, i D, I, J, K }. Each individual object to which we refer as the component of evaluation (CoE) can be also observed as an independent ToE. Each GoE is composed of (i) attributes, used for describing a particular group; (ii) assurance profile, which is the essential element for evaluation; (iii) associations, an element used to describe relationships between different groups in the scope of the evaluated target; and (iv) individual components. An individual parent object can be associated with N distinct successors (child objects), which we formally refer to as Associated Component Set (ACS), for which the following statements are valid: ACS D := ACS(COE D ) = {COE i, i F, G, H, L, M, N }. Usually ACS are used to derive a consolidated estimation of security properties that is afterwards vertically aggregated. The assessment of different information sets (i.e. analysis of a particular entity in the Cloud with respect to a specific set of properties) is described as the concept of Assurance levels (AL). The assurance level, illustrated in Table 2, qualitative level in context of security for evaluating predefined ToE, GoE or CoE where every individual CoE or GoE contributes directly to the assurance level of a ToE by meeting a set of SPs (i.e. a certain set of security criteria). Moreover, the SPs derive the AL per individual AC by taking into consideration the dependencies of the evaluated object, e.g. component, group or target of evaluation if such are present, illustrated in Table 2. Each AC contains k of SP (k number of SPs), definition (5), which are used for the assessment of individual assurance class. Due to the binary decision making concept which we propose and apply in our approach, there can be 2 k combinations of distinct SP states where 2 k > N, and N is the cardinality of AL, in terms of security properties (AL= {1, 2, 3, 4... N}). Thus, each individual combinations of SPs SP 1, SP 2, SP 3, SP 4...SP N, associated with a particular AC, are formally referred to as Security Property Vector (SPV) (definitions (2), (3), (4), (5), (6)). Security Property Vector defines the current state of an object by identifying particular set of security properties. Each SPV is associated with a particular assurance class (AL)(definition (1) - each AL as an element of an individual AC has a unique VS), whereby each class can comprise multiple SPVs formally referred as Vector Set (VS) (definition (6) - each AC is composed of a set of SPVs). Thus, in order to scale 2 k states over N assurance levels, we encode ranges in hexadecimal vectors that cluster a potential set of states that correspond to a particular SPV, as shown in Table 2. Furthermore, Table 2 illustrates how a set of relevant SPs is clustered per individual AC K. The left hand side of the table shows the SPVs, sorted by relevance, and all potential combinations for a particular security vector SPV = [SP 4, SP 3, SP 2, SP 1 ]. The right hand side shows a binary vector for AL i (i 1, 2, ), which associates particular set of SV vectors. At the bottom of the table the Hexadecimal representation of each particular binary AL vector is illustrated. These vectors are used to build policies for aggregation. Deliverable 5.2 Page 31 of 60

32 For each individual AC that is associated with a set of SPVs the particular SP (part of SPV) may vary. Nevertheless, every individual AC, regardless of the SPs, always has to have the same cardinality k (definition (5)), which is the number of. In order to efficiently aggregate the assurance across architectural layers, ACs first have to fulfil the definitions (5) and (6), stating that regardless of the AC, none of the SPs can be associated with more than one AC (definition (7) - the intersection of AC in context of SP is an empty set, i.e., the SP is present only in one AC). Although, the number N of ALs is variable in the general model and depends on the AC for the purpose of our empirical evaluation we will conduct the assessment using 7 ALs, therefore having a minimum of 3 SPs per AC to be able to map all assurance levels with SPVs. Depending on the property set that a particular entity (i.e. class component, group or even a whole target of evaluation) is assigned with and due to the dynamic behaviour of the Cloud, the AL will also vary. Hence, it is crucial to have an efficient framework for assessing assurance in a continuous manner without impacting on the performance of the evaluated service or collocated services. We propose a concept for the assurance aggregation through a recursive process, which aggregates the individual assurance levels depicted via security properties of the underlying associated objects (i.e. it calculates the overall assurance of the components that are associated with the root component). Furthermore, in order to illustrate our approach in a coherent way we abstract our evaluation target (e.g. service, virtual machine, storage, connection) via a general tree, Figures 3 and 4. However, due to the flexibility of our methodology design we are able to demonstrate different aggregation configurations, which will be later on shown in the Evaluation section, that can be based on Customer or providers requirements. Therefore, below we will show how we combine bitwise conjunction and our Aggregation policy. The overall assurance is derived by applying the tree traversal algorithm also described in Figure 2 (in line with definitions 8-12) and Assurance level policy Table 3 on the abstracted evaluation tree based model in Figure 1. Therefore by referring to Figure 4, we use the CoE A as root element of our ToE. The CoE A is associated with additional components, CoE B, CoE C and CoE D, which are associated with further child components. In order to avoid confusions by Deliverable 5.2 Page 32 of 60

33 Table 3: Assurance level policy. Assurance Level per distinct Assurance classes depicted with Hexadecimal vectors. We define minimal assurance level requirements (DAL V S ) of the objects that are in direct relationship with the parent object. It also defines the assurance level requirements per level of the parent object itself, AL V S. Additionally we define the minimum requirement for each AC in terms of AL, i.e. we define at which assurance level in an individual AC has to be reached to confirm the overall assurance of the object. complexity we demonstrate the assurance aggregation concept from two perspectives: vertical and horizontal aggregation. Moreover, we use a subset, Figure 3, of the Figure 1 for the describing these two aspects. Horizontal aggregation means that we conduct bit wise conjunction of SPVs, Figure 3, for individual objects (CoE B, CoE C, CoE D... CoE N ) in the same level under a root component (CoE A ), definition (8). However, the vertical aggregation uses the outcome of horizontal aggregation and assurance level policy from Table 3 to aggregate assurance vertically, in addition to definitions (9), (10), (11) and (12). The aggregation process derived by the aggregation algorithm, Figure 2, is depicted in Figure 4 in four simple steps. However, before we can conduct the aggregation procedure we have to calculate the assurance level of the individual component by applying the assurance level association illustrated in Table 2 which derives an Assurance level based on the security properties that individual component fulfils. Therefore our fundamental assumption to avoid repetition, is that the assurance level of each individual CoE is already present. Based on the post order tree traversal algorithm we start Step 1 with horizontal aggregation of CoE L, CoE M and CoE N, which are the leftmost lowest leafs (objects). This is done by applying the bitwise algorithm, Figure 2, across the CoEs which returns a conjunct security property vector DAL(ACi) SP V. Then, to vertically aggregate towards the CoE G, we conjunct the result of the underlying Associated Component Set (ACS) with the values of the component that we aggregate to CoE G. Then, in step 2, we again conduct horizontal aggregation but now of CoE E, CoE F and CoE G and vertically aggregate it towards CoE B. However, at this point we don t know the assurance levels CoE C and CoE D so we have to first aggregate assurance of their successors(coe H, CoE I, CoE J and CoE K ). Therefore, in step 3, since we have only one successor we immediately aggregate the value of CoE H towards CoE C. In step 4 we horizontally aggregate CoE I, CoE J and CoE K and then vertically towards CoE D. Finally, in step 5, we horizontally aggregate CoE B, CoE C and CoE D then in order to vertically aggregate towards CoE A. For the final overall assurance we apply our Aggregation policy 3 which defines a custom Assurance profile in terms of vectors. Now the underlying ACS assurance level is mapped towards the DAL V S, definition (9). Furthermore, Deliverable 5.2 Page 33 of 60

34 Figure 2: Assurance level calculation algorithm for associated objects used in definition (8). The procedure does the bitwise conjunction of the most significant bit and based on the result decides whether to discard the SPV that have 0 or 1 assigned to a particular bit that is being analysed. Furthermore, during each iteration, the procedure checks if the remaining vectors that define a particular component are a subset of one of the vector sets associated to a particular ALi, as shown in Figure 2, for a particular AC K Figure 3: Subtree of the abstracted use case model tree, Figure 4. The sub tree is used to illustrate the basic model of a general tree where the depth of the tree is one and the degree is N for demonstrating horizontal and vertical assurance aggregation methodology. the SP V (CoEi) V S is mapped towards the vector set of an individual corresponding assurance level AL V S. Based on these two vector sets,sp V (CoEi) V S and DAL V S, we can now calculate global assurance level or Target of Evaluation assurance level by using the minimum value of assurance associated. In case of multiple classes we would have to additionally cross map the assurance level of an individual class towards the policy to make the final overall assurance calculation, definition (12). Deliverable 5.2 Page 34 of 60

35 Figure 4: Abstracted use case model via a tree based structure. We demonstrate how assurance aggregation is conducted on hierarchical representation of CoEs via horizontal and vertical assurance aggregation that include assurance algorithm (Figure2), Assurance level association (Table 2) and Assurance aggregation policy (Figure 3) in 5 simple steps. Deliverable 5.2 Page 35 of 60

36 5 Evaluation Our methodology is being assessed through a real world scenario using different configuration examples. We use a set of pre-defined security properties and classes (Chapter 3) which are considered for assuring security of a cloud based service for processing and storing CI data. Classes, policies and aspects of the scenario are varied in 6 difference configuration examples, to illustrate the flexibility of our approach. In particular we refer to the case studies of Critical infrastructure services hosted on top of the cloud infrastructure that are within the scope of the SECCRIT project 23. However, we apply some minor degree of generalisation to allow relating our approach to a variety of use cases. For instance, to demonstrate our algorithm we abstract from a specific service via the evaluation scenarios explained below. The approach introduced in Section 4 is evaluated and explained in more details using two evaluation scenarios through three distinct configuration examples. However, before presenting the evaluation we will detail the Security properties, aggregation and association policies. 5.1 Evaluation scenario We demonstrate the methodology for assuring security properties of virtual services or infrastructure to either tenant, user or provider, via the use case scenario, presented in Figure 6, where a Critical infrastructure (CI) service is hosted on the top of the cloud environment (aligned with the demo scenarios in deliverable D ). Thus, our evaluation scenario described in this deliverable is derived from a realistic case for supporting Critical infrastructures from the SEC- CRIT context. The goal of the use case scenario is to demonstrate the application of AAF for ensuring both user and provider that the services hosted inside the Cloud environment meet the preferred security requirements. The effectiveness of our methodology lies in the focus on the quality level in terms of security by indicating there are no deviations over time or to which extent it is being met. Thus, we express our properties via its qualitative component that could be measured. Consequentially, we envision assurance as the quality level which is presented through a continuous assessment expressed via the qualitative properties of a system or a service. For the purpose of this deliverable we therefore use quality properties as an assurance that certain security objectives have been fulfilled at specific level across the Cloud stack, as shown in Figure 5. The security properties addressed by the AAF are clustered in security classes which we formally refer to as Assurance classes. Furthermore, assurance classes in AAF are derived based on the extensive research of security challenges and vulnerabilities of Critical infrastructures [BLS + 13] and the requirements of the industrial research partners. Hence, we focus, but do not limit ourselves, on the initial representative set of classes: Confidentiality Integrity Availability 23 SECCRIT project, 24 SECCRIT D2.1 Report on requirements and use cases, D2-1-Report_on_requirements_and_use_cases-v2.0.pdf Deliverable 5.2 Page 36 of 60

37 Figure 5: Data acquisition at various distinct components across the Cloud stack. This illustrates how the individual property should be monitored or how data acquisition can be mapped toward individual elements across the cloud stack. The goal is to abstract security properties via monitoring artefacts that collect evidence for a particular security property Scenario architecture A Critical Infrastructure Service (CIS) hosted on the top of the Cloud, as depicted in Figure 6, delivers high availability and resource intensive information analysis of sensitive data coming from external devices (e.g. Sensors, CCTV cameras, traffic control devices, mobile phones, etc.). The data is persistently delivered from devices located outside the Cloud s perimeter. The Cloud provider, which hosts our CIS, is required to guarantee sustainability, reliability and security of his infrastructure in order to support the critical services. However the Cloud provider usually only focuses on the internal challenges with the assumption that the data is acquired from authenticated external devices. The raw data (e.g. signal bits, video stream, data packages, pictures, etc.) acquired from external entities (e.g. Sensors, CCTV cameras, traffic control devices, mobile phones, etc.) is authorised via the access proxy service (at the service layer) used to accept, authorize and forward incoming requests. The proxy forwards the input requests to a Load Balancing as a Service component (LBaaS). The LBaaS services operates two load balancing modules, the data replication and the data analysis module. Data replication load balancing module, depicted on the left hand side of the Figure 6, handles all incoming requests and balances them among V M 1 and V M 2. These perform data replication across Deliverable 5.2 Page 37 of 60

38 Figure 6: Evaluation scenario. Illustrates a realistic scenario aligned with SECCRIT requirements and the demo scenarios defined in the SECCRIT project in which we evaluate our methodology. It shows external devices (e.g. CCTV cameras, traffic control devices) transmitting data to a central cloud based service. DB1, DB2, and DB3 databases. The virtual machines V M 1 and V M 2 additionally conduct a resource intense validation of the consistency of replicated data and encrypt the data before storing it. The data analysis load balancing module, depicted on the right hand side of Figure 6, conducts a resource intensive data analysis procedures spanned across V M 3 and V M 4. A number of virtual machines can be easily be scaled depending on the incoming workload deviation. Furthermore, to increase the availability of the data each databases (DB 1 and DB 2 ) is additionally backed up (DB 1 and, DB 2 ). In order to additionally highlight the dependencies between entities across the cloud stack we map each individual entity at the Tenant level with its corresponding physical infrastructure device which hosts the entity. Deliverable 5.2 Page 38 of 60

39 5.1.2 Data work-flow The data once being acquired, from external entities, is either being processed live and afterwards stored, or being stored first and then processed off-line. In any case, the Cloud provider should provide flexible scaling of resources in order to efficiently balance resource provisioning and tackle the unpredictable workload (especially when the data is processed live). We abstract the data life cycle through a process work-flow for the CIS, depicted in Figure 7, through the following abstract procedures: Store(), Retrieve() and Process(). Raw data (e.g. signal bits, video streams, pictures, etc.) that is continuously delivered from the external devices is either directly stored by initiating the Storage() procedure at the storage devices, or at the later point of time after processing is finished. Depending on the requirements the data can be processed live or off-line. Furthermore, to add additional security level the Store procedure additionally encrypts the data. However, if stored data is required for processing we initiate the Retrieve() procedure to retrieve and decrypt the data for further processing. In case of live or off-line data processing, data is processed by initiating the Process() procedure. CLOUD INTERNAL DATA WORKFLOW process() EXTERNAL DEVICES process() Intermediate Data store() Raw Data retrieve() store() Stored/ Encrypted Data Figure 7: Basic model of the data life cycle in our scenario. To better illustrate the use case which we will use later on for constructing the evaluation scenarios, we illustrate the basic data work-flow. The incoming raw data from external devices (e.g. Sensors, CCTV cameras, traffic control devices) is processed depending on the requirements, live or off-line, and afterwards stored in the cloud. Deliverable 5.2 Page 39 of 60

40 5.2 Correlation with the SECCRIT demo scenario Consolidation with SECCRIT industrial partners The above mentioned evaluation scenario 5.1 details how a critical infrastructure service is hosted on the Cloud infrastructure, which is then used for further evaluation. The evaluation scenario was engineered by consolidating with our SECCRIT industrial partners and the scenarios that they provided in SECCRIT deliverable For example in the case of the Valencia Traffic Control Centre the Access Proxy Service would forward directly the information to the LBaaS module, which is composed by two instances, one devoted to the data replication ensuring the integrity and availability of the data, and the other to the data analysis, providing scalability to the data analysis, so in any case of need the resources can be scaled up. Furthermore, Valencia scenario presents a great variety and diversity of data bases, to ensure the availability these have been replicated Interaction with Tools for Audit Trails and Root Cause Analysis As described in the updated version of Deliverable 5.1 [Con14c] the use of an independent API to check requirements would be beneficial. While trying to achieve increased transparency with respect to operations of the cloud infrastructure, we simultaneously try to achieve the objective of minimal disclosure of the cloud infrastructure provider s operational practices and resources as well as strict isolation between individual tenants. Figure 8 provides an overview of such an API for Tools for Audit Trails and Root Cause Analysis. Of particular interest is primarily the interface between the Cloud Infrastructure Provider and the Tenant Infrastructure Provider I T C. It is conceivable that such an interface or API not only provides information for tenants but also provides data for the described Assurance Methodology. According to Deliverable 5.1. several sources should be considered, i.e. Hardware, Operating System, Hypervisor, and Software. This could include any information about values from different devices as hosting cloud nodes, network devices (switch, firewall, IDS), CIMS, or from the auditing framework itself. Depending on the SLAs or legal requirements of a TIP other functions can be defined or the returned information can vary. For the Assurance Methodology it is conceivable that some assurance properties will be checked through tools for Audit Trails and Root Cause Analysis. Hence the Assurance Methodology can send inquiries directly to the API (I T C ) which is described in Deliverable 5.1 [Con14c]. If for example the Assurance Framework wants to know if an Anomaly Detection technique is present in the Cloud Infrastructure Layer it could easily send an inquiry to Tools for Audit Trails and Root Cause Analysis to check this property. On the other hand it is feasible that Tools for Audit Trails and Root Cause Analysis could request some values from Assurance Methodology. If for example a tenant wants to audit their actual assurance level they could easily send an inquiry to Tools for Audit Trails and Root Cause Analysis which will figure this out for them. It goes without saying one must pay attention to not build a feedback loop during implementation. It is also possible that auditing information is exchanged on a local host basis. Assuming that Assurance Methodology and Tools for Audit Trails and Root Cause Analysis components are running per physical host and are able to communicate whit each other. In this way, not every request has to be answered centrally. Some requests could be answered locally. 25 SECCRIT D2.1 Report on requirements and use cases, D2-1-Report_on_requirements_and_use_cases-v2.0.pdf Deliverable 5.2 Page 40 of 60

41 Resources Monitoring of SLA (at service level) Monitoring of SLA (at virtual tenant infrastructure level) Component A Client Devices CI Service Component B Service Components Tenant Infrastructure Application knowledge available Component Response Times C Throughput Availability Scope: This Tenant Interior View: System Internal Parameters Exterior View: Virtual Resource Parameters, e.g. CPU load, memory consumption, forwarded packets Scope: All tenants Substrate and Virtual Resource Parameters, e.g. CPU Load, Memory consumption, forwarded packets Cloud Infrastructure (Data Center) Service Operator Tenant Infrastructure Operator Operating Support System Tenant Infrastructure Management System Interior Interface Exterior Interface Cloud Infrastructure Management System Figure 8: A monitoring-oriented view identifying different interfaces I SO I ST I TC I TO I AC I AS I AT Auditor S Auditor T Auditor C Furthermore, it is worth mentioning that Tools for Audit Trails and Root Cause Analysis is only able to check if a specific technology is available, running or if a failure occurred. Currently it is not possible to check service level functionality with Tools for Audit Trails and Root Cause Analysis. Especially not when it leaves the sphere of the Cloud Infrastructure Provider. So it depends on the Assurance property if Tools for Audit Trails and Root Cause Analysis could provide additional data sets. Further interaction or a detailed overview between Assurance Methodology and Tools for Audit Trails and Root Cause Analysis or other RTD output will be discussed in Deliverable Evaluation policies and security properties A fundamental concept of our methodology are policies which we use to offer flexibility for assessing services and infrastructures in context of security. Thus, we have investigated security objectives and priorities among academic and industry experts which demonstrates the importance of following three Security classes: Confidentiality, Integrity and Availability, addressed in Section2, subsection 2.3. Hence, we focus on engineer policies for supporting these classes in the context of assurance. For supporting the Assurance methodology we need to define Assurance level association policy for individual assurance class and Assurance aggregation policies for individual and combined Assurance classes. Deliverable 5.2 Page 41 of 60

42 5.3.1 Security Properties Essential building block for deriving both policies (association policy and aggregation policy) are Security properties which we envisage as an individual entity used as a measure of confidence that certain security mechanisms within the cloud are fulfilled. Hence, we express properties via its qualitative component so they can be used as a measure of confidence. In Section 3 we detail the information about individual assurance properties and associate them with classes. Furthermore, we define each individual property in context of a measurable entity across the cloud stack. We investigated the relevance of security properties by assessing the importance based on the requirements of our demo partners in SECCRIT project. The results are shown in Tables 4, 5, 6 where we show a reduced set of ranked properties per assurance class (the extensive list of potential security properties can be found in appendix Tables 13, 11, 12). The order in which the security properties are ranked per class contribute to the assurance policies. In our case, the order was derived based on the requirements of SECCRIT demo partners. Table 4: Prioritized security properties for the assurance class Availability. Assurance Class Security properties SP bit rankings Load Balancing SP 1 Availability Horizontal resource scaling SP 2 Live migration SP 3 Live Backup SP 4 Table 5: Prioritized security properties for the assurance class Confidentiality. Assurance Class Security properties SP bit rankings Concurrent Session Control SP 1 Confidentiality Strong passwords SP 2 Encryption SP 3 Secure Data Deletion SP 4 Table 6: Prioritized security properties for the assurance class Integrity. Assurance Class Security properties SP bit rankings Data error correction SP 1 Integrity Service Behaviour Anomaly Detection SP 2 Information (data) consistency SP 3 Data alteration prevention SP Assurance association policies The first goal of this work was to demonstrating the assurance methodologies. However we have to also consider the security properties so that we can conduct the assessment, due to the fact that we intend to work continuously on deriving new properties we restrict ourselves to a modest set of properties per classes (i.e we use only 4 security properties and associate distinct combinations of these properties with Assurance levels) to reduce the complexity to demonstrating our methodology. The number of potential SPV combinations that we have to associate with an assurance level depends on the number of properties. If N is the number Deliverable 5.2 Page 42 of 60

43 of security properties then we have 2 N potential combination of procedures that have to be associated with these assurance levels. For the scope of this work we use 7 assurance levels, where AL=1 represents is the lowest level in terms of fulfilled security properties (i.e. the component that has the AL=1 has very few security mechanisms implemented therefore making it unprotected) and 7 is the highest meaning that all or at least most of security properties are fulfilled (i.e. it hast strong security mechanisms implemented). Furthermore, we also introduce a fundamental set of classes (confidentiality, integrity and availability), which has been investigated and surveyed across academic and industrial professionals and aligned with respect to the demo partner in SECCRIT project. We have also ranked the security properties used in the evaluation scenarios. In addition, we also carefully comprehended each individual security property and assign it to a class, Tables 5, 4 and 6. We have mainly considered the requirements and objectives primarily focusing on our demo partners, SECCRIT project requirements and the outcome of the risk assessment[bls + 13], when associating Assurance levels with possible combinations of these Security properties related to a particular assurance class. The results are shown in Tables 13, 8, 9 where our reduced set of properties is associated with assurance levels. The left hand side of the table depicts all potential occurrences of Security properties (introduced in Tables 4, 5, 6 detailed in section 3) in form of a Security Property Vector(SPV). On the right hand side Tables we cluster subset of SPVs considering individual Assurance levels (e.g in Table 4 the last three SPV=1101,1110,1111 are mapped with assurance level 7). The last row of the table shows a hexadecimal representation of an associated set of SPV for an individual Assurance level. These assurance level hexadecimal vectors are used in our aggregation policy to reduce the complexity and provide a better overview of the mappings. Table 7: Security property prioritisation policy for assurance class Availability, shows required bit mask values to achieve a specific assurance level - per components (SPV). (For SP 1, SP 2, SP 3, SP 4 see Table 4) Deliverable 5.2 Page 43 of 60

44 Table 8: Security property prioritisation policy for assurance class Confidentiality, shows required bit mask values to achieve a specific assurance level - per components (SPV). (For SP 1, SP 2, SP 3, SP 4 see Table 5) Table 9: Security property prioritisation policy for assurance class Integrity, shows required bit mask values to achieve a specific assurance level - per components (SPV). (For SP 1, SP 2, SP 3, SP 4 see Table 6) Deliverable 5.2 Page 44 of 60

45 5.3.3 Assurance aggregation policies One of the essential components of the assurance methodology that specifies the aggregation process, the Assurance aggregation policy, is depicted in Table 10. The Table describes how the aggregation process is conducted by taking in to account the underlying assurance level of the associated component set with the current status of the security properties (e.g. SPV = [1101]) of a root component. The advantage of our Aggregation policy lies in the flexibility of our methodology to adopt a variety of concepts for decision making ( e.g. XOR policies, conjunctions (and/or) XOR with entire vectors to apply component wise aggregation of security properties as well as vector based minimum value - these concepts can potentially derive a different way of how the overall assurance can be achieved). However, in the scope of this work we will only focus on how to aggregate assurance based on: logical bitwise conjunction, in addition, fine-tuned with the assurance policy rules. We engineered the Aggregation assurance policy, shown in Table 10, the same way as the Assurance association policies, in line with the requirements and objectives of the industrial partners of the SECCRIT project, SECCRIT project requirements and the outcome of the risk assessment [BLS + 13] analysis. Table 10: Assurance dependency policy. This table depicts how vertical aggregation supports the bitwise conjunction aggregation by implementing a fine tuned decision making policy for each individual assurance level, and additionally putting it in a correlation with multiple classes. The policy maps the property vector of the root component with the vector set AL V S which defines a subset of vectors for an individual assurance level to be fulfilled. Moreover, the property vector of the associated component set assurance level is mapped on DAL V S (Dependency Assurance Level). The DAL defines a subset of vectors for an individual assurance level to be fulfilled from the successors assurance level. Afterwards, the consolidated assurance level (CAL) is derived per class, based on the alignment of AL V S and DAL V S with the same level (in case they are not within one class we use the minimum value of the two). Finally by aligning CAL of an individual class with a corresponding level we derive the aggregated assurance level (in case they are not within one class we use the minimum value of the two). Deliverable 5.2 Page 45 of 60

46 5.4 Configuration examples and results Earlier in section 5.1 we introduced a a Cloud based architecture, Figure 6 for evaluating our methodology. This has been derived from our review of industrial and research requirements for hosting Critical infrastructures in Cloud-based environments. We will use this model in conjunction with challenges and requirements of the SECCRIT demonstration scenarios, for demonstrating the Assurance methodology. However, in order to demonstrate the current feature set of our methodology and at the same time reduce the complexity we will use two distinct use case scenarios that are sub-scenarios of the one depicted in the Figure 6. The first evaluation scenario will illustrate data consistency validation conducted via the load balancing service triggered by the heavy workload balancing. In the second evaluation scenario we consider again a heavy workload but balances between two virtual machines with an additional replicated across two distinct databases. Furthermore, in the second evaluation scenario, we have an additional level of complexity introduced by the databases used for data replication. The first evaluation scenario illustrates a simple one-level hierarchical architecture. Although, the second evaluation scenario differs, it is an extension of the first by adding an additional hierarchical degree. For both scenarios we apply a class-wise aggregation via the bit-wise conjunction methodology. Finally, we demonstrate our multi-class aggregation methodology with a single-component based evaluation scenario. For the first and the second evaluation scenario we perform the class wise aggregation separately on two distinct assurance classes Evaluation scenarios A1-A3: Data consistency validation via two-level based hierarchy model The evaluation scenario analyses a Load balancing service by observing only the first level of successors (V M 1 and V M 2 ) and abstracting from the underlying infrastructure with predefined assurance level (underlying assurance table). We apply a class-wise conjunction for Assurance class Integrity and assurance class Confidentiality. We conduct the assessment with the initial assumption of assurance, shown in underlying assurance table in Figure 9, by assuming that the underlying infrastructure is assured. The first and the second step marked in the figure 9 can be performed in parallel. However, we will describe them sequentially starting with step one. We start with the vertical aggregation by applying our assurance level calculation algorithm (Section 4, Figure 2), we conduct bitwise conjunction SPV(UAL) = [1111] and SPV(V M 1 ) = [0101] that results in AL V M1 =[0101]= 3. The same process applies for the step 2 which results in AL V M2 =[0111]= 4. Next, as an intermediate step, we conduct the horizontal aggregation of the results gained at the first two steps where we calculated assurance level of the virtual machines AL V M1 and AL V M2. The outcome of the horizontal aggregation is depicted in step three (colour coded in orange), inside the square brackets at the right hand side of the formula. However, due to the fact that we are using a conjunction during the whole aggregation process we are able to demonstrate the complexity of the aggregation at the root component. Step three, derives the conjunction of the underlying horizontal aggregation (conjunction of virtual machine assurance levels AL V M1 and AL V M2 ) with the load balancing module SP V (LBM 2 ) assurance level via the vertical aggregation which results in AL(ToE)= [0001] = 1. Although the underlying infrastructure has the highest assurance level both V M 1 and V M 2 lack of the data alteration prevention security property support. This results (depending on the individual SPV) in a lower assurance level. Unfortunately regardless the fact that LBM 2 supports data alteration prevention, the lack of data alteration prevention at the underlying levels AL V M1 cannot be compensated. In addition, AL V M1 fails to support service anomaly detection, LBM 2 Deliverable 5.2 Page 46 of 60

47 Scenario A1: Conjunction dependency policy of assurance class integrity Copyright SECCRIT Consortium Tenant Infrastructure Level AL(VM 1 ) = SPV (VM 1 ) SPV (UAL) = = 0101 (AL=3) VM 1 LBM 2 VM 1 consistency validation and encryption SPV Assurance Level SPV AL Load balancing module for data validation VM 2 consistency validation and encryption AL(ToE) = SPV(LBM 2 ) [AL (VM 1 ) AL (VM 2 ) ] = 1011 [ ] = 0001 (AL=1) Step (1) Step (2) Security properties Assurance Classes SP 4 SP 3 SP 2 SP 1 Integrity LBM 2 Step (3) AL(VM 2 ) = SPV (VM 2 ) SPV (UAL) = = 0111 (AL=4) VM 2 Security properties Security properties SPV Assurance Level SPV AL Assurance Classes SP 4 SP 3 SP 2 SP 1 Integrity SPV Assurance Level SPV AL Assurance Classes SP 4 SP 3 SP 2 SP 1 Integrity Physical Infrastructure Level Underlying Assurance Security properties Assurance Level Assurance Classes SP 4 SP 3 SP 2 SP 1 UAL Integrity Figure 9: Evaluation scenario A1: Data consistency validation via a two-level based hierarchy model for assurance class Integrity. This scenario shows how in two levels, root and first level successors, assurance is aggregated based on bitwise conjunction, per class. However, the assumption of the underlying assurance is used to illustrate a case model when considering distinct stakeholders. cannot conduct any consistency validation which therefore results in a significant degradation of the overall assurance. Next, we perform the assessment of the same evaluation scenario (Figure 10). However considering the assurance class confidentiality. We are starting with the same assumption as previously that underlying infrastructure is at the highest assurance level. The vertical aggregation are performed parallel for step one and two. This results for the first Virtual machine in AL V M1 = 3, and for the second virtual machine AL V M1 = 5. Next the horizontal aggregation is performed, depicted in step three(colour coded in orange), which is then vertical aggregated with SP V (LBM 2 ) and resulted as AL(ToE)= [1000] = 5. The presence of the secure data deletion security property across( the highest significant property for the assurance class Confidentiality)maintains high assurance, despite of the support for concurrent session control, strong passwords and encryption is not consistent. Therefore the overall assurance for assurance class confidentiality is AL = 5. In Figure 11 we illustrate the third configuration example of the first evaluation scenario, where we derive the overall assurance by aligning the assurance classes (Integrity and Confidentiality) Deliverable 5.2 Page 47 of 60

48 Scenario A2: Conjunction dependency policy of assurance class Confidentiality Copyright SECCRIT Consortium Tenant Infrastructure Level LBM 2 Load balancing module for data validation AL(ToE i ) = SPV(LBM 2 ) [AL (VM 1 ) AL (VM 2 ) ] = 1011 [ ] = 1000(AL=5) LBM 2 Security properties Step (3) SPV Assurance Level SPV AL Assurance Classes SP 4 SP 3 SP 2 SP 1 Confidentiality AL(VM 1 ) = SPV (VM 1 ) SPV (UAL) = = 1000(AL=3) VM 1 Step (1) Step (2) Security properties SPV Assurance Level Assurance Classes SP 4 SP 3 SP 2 SP 1 SPV AL Confidentiality VM 1 consistency validation and encryption VM 2 consistency validation and encryption AL(VM 2 ) = SPV (VM 2 ) SPV (UAL) = = 1001 (AL=5) VM 2 Security properties SPV Assurance Level SPV AL Assurance Classes SP 4 SP 3 SP 2 SP 1 Confidentiality Physical Infrastructure Level Underlying Assurance Security properties Assurance Level Assurance Classes SP 4 SP 3 SP 2 SP 1 UAL Confidentiality Figure 10: Evaluation scenario A2: Data consistency validation via two-level based hierarchy model for assurance class confidentiality. This scenario demonstrates how two levels ( root and first level successors) can be aggregated based on bitwise conjunction per class. However, the the lower assurance levels are used to illustrate a case model when considering distinct stakeholders. Figure 11: Evaluation scenario A3: Data consistency validation via two-level based hierarchy model, for combined assurance aggregation of integrity and confidentiality classes. Here we illustrate the combination of individual classes (case A1 and A2) based on the conjunction method we derive the individual assurance class SPV. This SPV can then be mapped in to an assurance level either on assurance dependency policy 10 or prioritisation policy 13, 8 and 9. from previous configuration examples. This setup of security properties for individual assurance class is considered as Assurance profile of our Target of evaluation. Deliverable 5.2 Page 48 of 60