A Study of Implementing an Information Security
Management System for Open Source Cloud Computing
George SUCIU, Vlad POENARU, Cristian CERNAT, Traian
MILITARU, Gyorgy TODORAN
Faculty of Electronics, Telecommunications and Information Technology POLITEHNICA University Bucharest ROMANIA george@beia.roAbstract: An Information Security Management System (ISMS) contains a coordinated set of activities, processes, controls, and policies with the purpose of protecting and managing the information assets within an organization. In this paper we present the way in which an ISMS as specified in the ISO 27001 can be applied for the cloud and implemented on our test platform based on SlapOS, the first open source provisioning and billing system for distributed cloud computing. The goal of this paper is to demonstrate a new and easier way to manage security for the cloud, with a specific focus on distributed cloud computing. We will present the results measured by applying ISMS controls for ensuring levels of QoS and SLA according to contracts, moreover also optimizing the costs and resources used by the cloud platform.
Key-Words: cloud, open source, distributed cloud computing, cloud security, ISMS
1. Introduction
Recent research on Cloud Computing has focused on the implementation of Quality of Service (QoS), Service Level Agreements (SLA) and operation of large Data Centers. However, in case of Force Majeure such as natural disaster, strike, terrorism, unpreventable accident, etc., QoS and SLA no longer apply. Rather than centralizing Cloud Computing resources in large data centers, Distributed Cloud Computing resources are aggregated from a grid of standard PCs hosted in homes, offices and small data centers.
The strategic and legal requirements have resulted in the standardization of the ISMS that implies much more than technical security. Our paper presents the study of applying the principles of ISO27001 for implementing an ISMS for distributed cloud computing.
SlapOS [1] is based on a grid computing daemon – called slapgrid – which is capable of installing any software on a PC and instantiate any number of processes of potentially infinite duration of any installed software. Slapgrid daemon receives requests from a central scheduler – the SlapOS Master – which
collects back accounting information from each process. SlapOS Master follows an Enterprise Resource Planning (ERP) model to handle at the same time process allocation optimization and billing.
The paper is structured as follows: we describe in Section II a distributed architecture for cloud platforms and identify common security functions. Section III presents an example to design and implement an ISMS on the open source cloud test platform. Section IV describes an approach to test different security scenarios and an example of results obtained by using the ISO27001 framework. We conclude in section V with a summary of the
contributions and future work
envisioned.
2. Distributed Cloud
Computing Architecture
In this chapter we are going to provide an overview of our cloud computing test platform based on SlapOS architecture and are going in particular to explain the role of Master node and Slave nodes, as well as the software components which
they rely on to operate a distributed cloud for security applications.
SlapOS is an open source Cloud Operating system which was inspired by research in Grid Computing and in particular by BonjourGrid [2] a meta Desktop Grid middleware for the coordination of multiple instances of Desktop Grid middleware. It is based on the motto that ”everything is a process”.
2.1. SlapOS Master-Slave Design
SlapOS is based on a Master and Slave design. Slave nodes request to Master nodes which software they should install, which software they should run and report to Master node how much resources each running software has been using for a certain period of time. Master nodes keep track of available slave node capacity and available software. Master node also acts as a Web portal and Web service so that end users and software bots can request
software instances which are
instantiated and run on Slave nodes. Master nodes are stateful. Slave nodes are stateless. More precisely, all information required to rebuild a Slave node is stored in the Master node. This may include the URL of a backup service which keeps a online copy of data so that in case of failure of a Slave node, a replacement Slave node can be rebuilt with the same data.
It is thus very important to make sure that the state data present in Master node is well protected. This could be implemented by hosting Master node on a trusted IaaS infrastructure with redundant resource. Or - better - by hosting multiple Master nodes on a many Slave nodes located in different regions of the world thanks to appropriate data redundancy heuristic. We are touching here the first reflexive nature of SlapOS.
A SlapOS master is normally a running instance of SlapOS Master software instantiated on a collection of Slave nodes which, together, form a trusted hosting infrastructure. In other terms, SlapOS is self-hosted, as shown in Figure 1.
Figure 1. Example of SlapOS Master – Slave Architecture
Slave nodes request to Master nodes which software they should install, which software they show run and report to Master node how much resources each running software has been using for a certain period of time. Master nodes keep track of available slave node capacity and available software. Master node also acts as a Web portal and Web service so that end users and software bots can request software instances which are instantiated and run on Slave nodes. Master nodes are stateful. Slave nodes are stateless. More precisely, all information required to rebuild a Slave node is stored in the Master node. This may include the URL of a backup service which keeps a online copy of data so that in case of failure of a Slave node, a replacement Slave node can be rebuilt with the same data.
2.2. SlapOS Kernel
SlapOS relies on mature software: buildout and supervisord [1]. Both software are controlled by SLAPGrid, the only original software of SlapOS. SLAPGrid acts as a glue between SlapOS Master node (ERP5) and both buildout and supervisord, as shown in Figure 2. SLAPGrid requests to SlapOS Master Node which software should be installed and executed. SLAPGrid uses buildout to install software and supervisord to start and stop software processes. SLAPGrid also collects accounting data produced by each running software and sends it back to SlapOS Master.
Figure 2. SlapOS Kernel and User Software implementation
SlapOS master nodes keep track of the identity of all parties which are involved in the process of requesting Cloud resources, accounting Cloud resources and billing Cloud resources. This includes end users (Person) and their company (Organisation). It includes suppliers of cloud resources as well as consumers of cloud resources. It also includes so-called computer partitions which may run a software robot to request Cloud resources without human intervention. It also includes Slave nodes which need to request to SlapOS master which resources should be allocated. SlapOS generates X509 certificates for each type of identity: X509 certificates for people who login, an X509 certificate for each server which contributes to the resources of SlapOS and an X509 for each running software instance which may need to request or notify SlapOS master.
A SlapOS Master node with a single Slave node, a single user and 10 computer partitions will thus generate up to 12 X509 certificates: one for the slave, one for the user and 10 for computer partitions. Any user, software or slave node with an X509 certificate may request resources to SlapOS Master node. SlapOS Master node plays here the same role as the back office of a marketplace. Each allocation request is recorded in SlapOS Master node as if it were a resource trading contract in which a resource consumer requests a given resource under certain conditions. The resource can be a NoSQL storage, a
virtual machine, an ERP, etc. The conditions can include price, region (ex. China) or specific hardware (ex. 64 bit CPU). Conditions are somehow called Service Level Agreements (SLA) in other architectures but they are considered here rather as trading specifications that guarantees. It is even possible to specify a given computer rather than relying on the automated marketplace logic of SlapOS Master [6].
2.3. Common Security Problems
Many real-world systems involve large numbers of highly interconnected over Internet heterogeneous components. The Cloud is among one of the more promising system that will be deployed at a large scale in the near future because the field counts yet on many success stories: Amazon EC2, Windows Azure or Google App Engine [3].
The architecture used in our approach is a distributed cloud environment that is deployed on “volunteer PCs” at home, office or in small data centers and run SlapOS open source cloud provisioning system, either standalone or in combination with existing virtualization
technologies (OpenStack [4],
OpenNebula [5], Eucalyptus [6], OCCI [7], VMWare, etc.).
Based on the implemented scenario, several question rise regarding its performances and security. SlapOS nodes report on resources used and trusting client to report billing values is a well-known security issue. The security mechanisms included in SlapOS are setup to prevent a node from cheating on billing values reported. However traffic on unencrypted links could be intercepted and it is possible for a node to join the cloud and start sniffing sensitive data.
Also some time is needed before a new application gets installed on a node and becomes ready to use. Questions arise about slow response and how does the master node handle this delay? The specific provisioning strategy could be improved to always keep a buffer of ready-to-use applications.
SlapOS uses buildout and a single URL to describe how to build and install software. This approach could be extended in different ways. Ideally, it should be possible to install software using other build systems or even by using packages (DEB, RPM).
SlapOS should also soon serve as a platform for open source software publisher to turn their software into multi-tenant SaaS. On the other hand know how is attracted continuously by companies such as Google, Facebook and Microsoft where it remains secret. Nevertheless development is still needed for Slaprunner, the SlapOS buildout web based runner so that software profiles and release versions can be better managed and many other web-based applications added to the software release directory.
3. ISMS Test Platform
Implementation Details
We will use the SlapOS platform
implemented during the “Cloud
Consulting” project [8] hosted on several servers running Ubuntu Linux – Apache – MySQL template with current software release.
SlapOS Master runs ERP5 Cloud Engine, a version of ERP5 open source ERP capable of allocating processes in relation with accounting and billing rules. Initial versions of SlapOS Master were installed and configured by human. Newer versions of SlapOS Master are implemented themselves as SlapOS Nodes, in a completely reflexive ways. A SlapOS Master can thus allocate a SlapOS Master which in turn can allocate another SlapOS Master, etc.
By default, SlapOS Master acts as an automatic marketplace. Requests are processed by trying to find a Slave node which meets all conditions which were specified. SlapOS thus needs to know which resources are available at a given time, at which price and under which characteristics. Last, SlapOS Master also needs to know which software can be installed on which Slave node and under which conditions
SlapOS Slave nodes are relatively simple compared to the Master node. Every slave node needs to run software requested by the Master node. It is thus on the Slave nodes that software is installed. To save disk space, Slave nodes only install the software which they really need.
Each slave node is divided into a certain number of so-called computer partitions. One may view a computer partition as a lightweight secure container, based on UNIX users and directories rather than on virtualization. A typical barebone PC can easily provide 100 computer partitions and can thus run 100 wordpress blogs or 100 e-commerce sites, each of which with its own independent database. A larger server can contain 200 to 500 computer partitions.
SlapOS approach of computer partitions was designed to reduce costs drastically compared to approaches based on a disk images and virtualization. As presented in Figure 3, our current implementation does not prevent from running virtualization software inside a computer partition, which makes SlapOS at the same time cost efficient and compatible with legacy software.
Figure 3. SlapOS Slave security implementation
SlapOS Slave software consists of a POSIX operating system, SlapGRID, supervisord and buildout. SlapOS is designed to run on any operating system which supports GNU's glibc and supervisord. Such operating systems include for example GNU/Linux, FreeBSD, MacOS/X, Solaris, AIX, etc.
3. Security and Risk
Management Solution
The lack of direct resource control in the cloud raises concerns about data privacy violations, particularly abuse or leakage of sensitive information by service providers. Cryptography is a remedy but alone can’t enforce the security demanded by common cloud computing services. Among its most powerful tools is fully homomorphic encryption (FHE), dubbed by some the field’s “Holy Grail,” and recently realized as a fully functional construct with seeming promise for cloud privacy [9].
We define a strategy of risk management as shown in Figure 4 and identify that even with such powerful tools as FHE, users of cloud services will also need to rely on other forms of
security enforcement, such as
tamperproof hardware, distributed
computing, and complex trust
ecosystems.
Figure. 4. ISMS risk management strategies For risk assessment we define the following components:
• E = Evaluated element (to reduce value)
• T = Threat (to reduce) • V = Vulnerability (to reduce) • C = Existing Controls (for detection and recovery)
• P = Probability
• I = Impact
We describe a risk function graphic as presented in Figure 5, with axis labels used in the formula below:
R = f ( E, T, V, C, P, I) (1)
Figure 5. ISMS risk management function Threats are defined as potential causes of an unwanted incident that may lead to damage of systems or organization. Example of threats:
• Natural disasters – earthquakes, lightning, floods
• Human – lack of personnel, maintenance errors, user errors
• Technology – network
breakdown, traffic overload, hardware malfunction
• Deliberate hacker attacks – phishing, malware, exploit, iFrame, XSS, etc.
• Accidental threats
Threats can be defined by using a scale for the frequency, in general three or four levels being sufficient as presented in Table 1.
Table 1. Threat frequency Threats Frequency
1 Less than 1 per year
2 Between 1 and 12 per year
3 More than 1 per year
An impact scale can be defined as shown in Table 2 where we consider financial loss, the cost of service disruption and the organization’s affected reputation. Table 2. Impact scale
Impact Financial Reputation Service disruption 1 <1000
Euro Internally, inside organization < 5min 2 Between Locally, regionally between 3 >50000 Euro External, national, > 2 hours
customers
Vulnerability is considered a weakness of resources or group of resources in the cloud that can be exploited by a threat. A vulnerability itself does not cause damage but identifies the problem of a resource regarding the physical
environment, human resources,
procedures, controls, equipment and service delivery.
Identified vulnerabilities for our cloud test platform are:
• Lack of key personnel • Unprotected cables • Instable electrical grid • Lack of security awareness • Unprotected doors
• Errors in allocating password rights
• Firewall missing
• Insufficient security training For calculation of exploitation probability of a vulnerability we define levels as specified in Table 3 where we can include data from sources that show the frequency of a event (number of errors, attacks), other available sources (log files, audits, statistics, trend reports, newsgroup discussions).
The probability for each threat and each vulnerability can be considered separately and the probability is included in the definition of each of the elements. This can result in complex probability matrix that may be difficult to calculate the risk for large risk registers.
Table 3. Vulnerability exploitation Vulnerability Element
compromised Exploitation easiness 1 Minimal effect, under 10% of element value Easy to exploit (publically known) and no protection installed 2 Between 10%
and 90% Vulnerability can be exploited (not publically known) and protection is installed 3 Maximum effect, over 90% Vulnerability is hard to exploit and a compromised good protection is installed
A condensed risk scale can be used as shown in Table 4 for the following ranges:
Low Risk (L) : 0 – 2 Medium Risk (M) : 3 – 5 High Risk (H) : 6 – 8 Table. 4. Risk scale
Pr o b ab ili ty VL ( ve ry ra re) L (r ar e) M (p o ssibl e) H (f re q u en t) H ( ve ry fr eq u en t) Impact Very low 0 1 2 3 4 Low 1 2 3 4 5 Medium 2 3 4 5 6 High 3 4 5 6 7 Very High 4 5 6 7 8 A risk management matrix is calculated as presented in Table 5.
Table. 5. Risk management example
Information Threat Vulnerability Impa
ct sk Ri Clients and
contracts Fire Not stored in fireproof container
3 9
H
HR details Information
loss Lack of access control 2 M 4 Marketing
strategy plan Espionage Lack of access control 3 L 3 Infrastructure
plan Information loss Lack content filter of 2 M 4 Financial
results Information loss Unhappy internal stakeh.
4 M Price lists Information
loss Unhappy internal stakeh.
2 L Also the probability of a risk can be calculated by considering the combined probability of an incident threat-vulnerability.
4. Conclusion and Future Work
Threats and vulnerabilities regarding information security are pushing organizations to better protect their valuable information and resources byusing an information security
management system.
Obtaining a security certificate such as ISO 27000 can help cloud providers to
improve users trust in the cloud platform security. However, such standards are still far from covering the full complexity of the distributed cloud computing model.
We introduce a new cloud security management approach based on our distributed cloud computing platform that allows collaboration between cloud providers, service providers and service consumers in managing the security of the cloud platform and the hosted services. Like all forms of outsourcing, cloud computing raises serious concerns about the security of the data assets that are outsourced to providers of cloud services.
The current ISMSs must therefore be extended to the virtual environments by adapting the security controls to cloud architectures and address new types of threats and vulnerabilities, such as for example cascaded attacks or mutual attacks between the virtual machines. SlapOS is capable of allocating virtual machines, application servers, databases and even ERP applications beyond the borders of IaaS, PaaS and SaaS in Cloud Computing. Also SlapOS is in reality much more reliable than traditional approaches to Cloud because, by selecting independent sources, SlapOS can survive any case of force majeure: strike, earthquake, political decision, electricity breakout, etc. That said, SlapOS can also be used to operate traditional data centers more efficiently and preserve existing SLA and QoS specified in contracts.
As future work we envision a security management platform that provides a
forum for specifying security
requirements and the possibility to automatically test and report the
information about the effectiveness of implemented security controls.
References
[1] Jean-Paul Smets-Solanes, Christophe
Cerin and Romain Courteaud:
“SlapOS: A Multi-Purpose Distributed Cloud Operating System Based on an ERP Billing Model”, IEEE International Conference on Services Computing 2011, July 2011, pp. 765-766. [2] Heithem Abbes, Christophe Cerin and
Mohamed Jemni:“BonjourGrid:
Orchestration of multi-instances of grid middlewares on institutional Desktop Grids”, IEEE International Symposium on Parallel & Distributed Processing 2009, May 2009, pp. 1-8. [3] Tze Ng and Guohui Wang: "The
impact of virtualization on network performance of Amazon EC2 data center", IEEE INFOCOM 2010 - 29th IEEE International Conference on Computer Communications, Vol. 29, no. 01, March 2010, pp. 1 – 9 [4] http://www.openstack.org/ (Jun. 2012) [5] http://opennebula.org/ (Jun. 2012) [6] http://open.eucalyptus.com/ (Jun. 2012) [7] http://occi-wg.org/ (Jun. 2012) [8] George Suciu, Vlad Andrei Poenaru,
Cristian George Cernat, Gyorgy Todoran and Traian Lucian Militaru: “ERP and E-Business Application
Deployment in Open Source
Distributed Cloud Systems”, The Eleventh International Conference on Informatics in Economy IE 2012, May 2012, pp. 12-17.
[9] Martin Van Dijk and Ari Juels: “On the Impossibility of Cryptography Alone for Privacy-Preserving Cloud Computing”, Computing, vol. 305, 2010, pp. 1–8
