1 Arbeitsberichte der Hochschule für Wirtschaft FHNW Nr. 28 Enterprise Architectures for Cloud Computing Laura Aureli, Arianna Pierfranceschi, Holger Wache ISSN Nr (Print) Nr (Online) ISBN Nr Institut Datum Juni 2012 Institut für Wirtschaftsinformatik IWI Jahr Hochschule für Wirtschaft FHNW und der Autor bzw. die Autorin. Jede Reproduktion, auch von Teilen und unabhängig vom Medium, ist nur mit Genehmigung der Hochschule für Wirtschaft FHNW und des Autors bzw. der Autorin gestattet. Enterprise Architectures for Cloud Computing von L. Aureli, A. Pierfranceschi, H. Wache
2 Enterprise Architectures for Cloud Computing von L. Aureli, A. Pierfranceschi, H. Wache
3 Technical Report Enterprise Architectures for Cloud Computing Laura Aureli, Arianna Pierfranceschi and Holger Wache 2012 University of Applied Sciences and Arts Northwestern Switzerland School of Business
4 2 Responsibility Holger Wache Institute for Information Systems School of Business University of Applied Sciences and Arts Northwestern Switzerland Phone: Laura Aureli Institute for Information Systems School of Business University of Applied Sciences and Arts Northwestern Switzerland Arianna Pierfranceschi Institute for Information Systems School of Business University of Applied Sciences and Arts Northwestern Switzerland
5 Contents 3 Contents 1. Introduction Problem Goal Requirements Enterprise Architectures Proposed approach Structure of the paper Background Introduction General Concepts of Cloud Computing Software as a Service Platform as a Service Infrastructure as a Service Public Cloud Computing Private Cloud Computing Hybrid Cloud Computing Enterprise Architectures Main problems in Cloud Computing Portability Privacy Interrelation between Cloud Computing and Enterprise Architectures State of the Art Best Practices Application security and encryption Governance and risk management Incident management Portability and interoperability Privacy Security and disaster recovery Service availability Representations Extensions Graphical representations Domains and generic framework Graphical representations applied to a generic framework
6 Contents Knowledge representations Application security and encryption Governance and risk management Incident management Portability and interoperability Privacy Security and disaster recovery Service availability SLA representation Conclusions 72 A. Business Rules 76 A.1. Application security and encryption A.2. Governance and risk management A.3. Incident management A.4. Portability and interoperability A.5. Privacy A.6. Service availability
7 List of Figures 5 List of Figures 5.1. Pyramid representation of the Enterprise Architecture Framework Extended Graphical representation for application security and encryption domain Graphical representation for governance and risk management domain Graphical representation for incident management domain Graphical representation for portability and interoperability domain Graphical representation for privacy domain Graphical representation for service availability domain Graphical representation of the complete framework Graphical representation of the technology level adapted from Hinkelmann (2011) Graphical representation of the technology level adapted from Hinkelmann (2011) Graphical representation of an internal behavior of an application adapted from Hinkelmann (2011) Graphical representation of a structure of one or more applications or components adapted from Hinkelmann (2011) UML graphical representation for the data level BPMN graphical representation for the business level Graphical representations of terms and fact types involved in the domain application security and encryption Graphical representations of terms and fact types involved in the domain governance and risk management Graphical representations of terms and fact types involved in the domain incident management Graphical representations of terms and fact types involved in the domain portability and interoperability Graphical representations of terms and fact types involved in the domain privacy Graphical representations of terms and fact types involved in the domain service availability Terms and fact types involved in an SLA
8 List of Tables 6 List of Tables 5.1. Standards used in Cloud Computing Service availability decision table Mapping between knowledge representation, graphic representations and best practices affected
9 1. Introduction 7 1. Introduction 1.1. Problem As stated in Velte et al. (2009), cloud computing allows to use applications that are physically running in a different location than the computer on which the user is working. Cloud computing includes also the usage of platforms and infrastructures physically stored in places different than the company or user s site. This can be considered as a new way to make business, since it allows companies not to own their infrastructures. The same applies to platforms and applications. For these reasons, the usage of cloud computing can give value to companies. For this reason, many companies desire to move into the cloud. At the moment there aren t specific practices that describe how to do it, taking into account the main characteristics of the considered enterprise. These features can span across many levels, starting form the organizational structure of the company, through the definition of its processes and procedures, the organization of its information system as well as the architecture of its infrastructure. The main reasons to move into the cloud, as stated by European Network and Information Security Agency (2009), are to cut costs in hardware and software, to have more flexibility and scalability of IT resources, to guarantee business continuity and disaster recovery, to increase computing capacity and business performance. Moreover, Ebneter et al. (2010) state that cloud computing enables the sustainability and growth of start up companies or companies shifting in new areas of activities. This means that start up companies are facilitated, thanks to the benefits - listed above - that going into the cloud delivers. In a similar way, enterprise architecture frameworks can deliver value too. This is done, since they allow to represent the company structure, its business processes and information systems, as well as its infrastructure, as described by Architectures for Enterprise Integration (2003). Thus, companies use enterprise architecture frameworks to describe their main features. What is not yet clear is if a company, to evaluate the possibility to go into the cloud, can just consider its architectural description or if it s necessary to add more features.
10 1. Introduction 8 The possibility to extend a generic enterprise architecture representation should be considered in order to be able to describe all the features that are important to decide to go into the cloud. As an example, it will be shown that features of the enterprise related to security and privacy of data, interoperability and portability, encryption of data, governance and risk management must not be underestimated, but they must be considered and represented in terms of knowledge, as well as graphically, to give a more comprehensive view of the company. Each company has a cloud potential. The cloud potential reflects the readiness of the company to shift its business activities - part or all of them - into a cloud environment. The readiness is related, as already said, to the security of data and processes, risk management procedures, ability to change cloud provider or to interoperate with many of them. The lack of usage of enterprise architecture extensions can lead to a wrong evaluation of the potential of the company to go into the cloud. The cloud potential can be either under-evaluated or over-evaluated. In both cases, there will be serious consequences. On the one hand, if the company s potential is high but it s not made visible, there could be losses in terms of money, flexibility and scalability of resources, as already explained at the beginning of the description of the problem. On the other hand, if the company s potential is effectively low but it s over-evaluated, this could lead to problems related with security of data, privacy, governance or with the unreadiness to interoperate with other cloud providers. Potentially, the second scenario can be considered more dangerous than the first one either in terms of possible damages or in terms of the image of the company, possibly leading to a reduction of the business and related revenues. Moreover, the usage of extensions could help not only IT people, but also business employees, to understand better company s potential. This allow to have an overall understanding of company s capabilities, clear to different departments of the company Goal The goal of this work is related with one main question: can companies use the existing enterprise architecture frameworks to understand if they have potential to go into the cloud? This means, understand if the architectural description given by one of the available enterprise architecture frameworks, is enough to evaluate the company cloud-readiness. More precisely, the goal is to find out if the architectural description of the company already includes specific features. These are important characteristics to consider before deciding to go into the cloud. As said in the problem description, the main ones
11 1. Introduction 9 are related to security and privacy of data, interoperability and portability, encryption of data as well as governance and risk management. Moreover, these features should also be understandable by business people. To satisfy this requirement, a graphical representation of them is needed. A graphical representation helps the company to quickly identify the main issues related to the shift to a cloud computing environment. In this way, the cloud-readiness analysis that has been done can be understood by company s employees with different backgrounds. If any of the existing frameworks don t have the needed features for the evaluation, then a way to add these characteristics has to be found. In this case, it s likely that the generic framework will need some extensions - graphical but also in terms of knowledge, that is what the extension means, refers to, as well as how it s derived. In this case, the goal is to give some proposals about the extensions to apply to the enterprise architectural description of a company. At this time, it s already possible to understand that it s important to extend the common architectural representations of enterprises, especially to help managers or responsible people with a realistic evaluation of the possibility to go into the cloud. Our goal is to give suggestions on how to extend these generic representations. Later on in the paper, it will be shown that it s possible to group these suggestions in main areas. For each group of features considered, there will be given advices on how to extend the knowledge (that is, the information needed and the related analysis of it) and the graphic representations. These suggestions, also called best practices, allow the company to describe its features related to the kind of data it uses, how sensitive they are, the issues related with privacy and the need to encrypt them. They also span across the need to use standard data formats and applications interfaces to guarantee portability, as well as interoperability. Once provided these best practices, companies will be able to structure their features related to those main areas and to understand what are the possible problems that they can meet during the journey going into the cloud. Since the recommendations are expressed in natural language and there can be many of them, providing a graphical representation to be added to the architectural representation of the enterprise, would be a solution. In this way, the evaluation of the company s potential and the awareness of possible problems will be easier, faster, understandable and clear also to business people. To relate the graphical representation with the best practices expressed in natural language, it s necessary to express the knowledge behind them. The knowledge representation helps in expressing in a more formal way, what are the main issues, for each
12 1. Introduction 10 of the identified areas, that should be considered. As an example, formalisms that can be used for the knowledge representation, can vary from business rules - to define what should be true and enforced, what is suggested and what should or must be avoided - to UML representations to describe relations between different components, ontologies to represent the semantics of the considered scenario or F-Logic. A summary of the proposed approach can be found later on in the introduction. Details about the representation extensions, will be shown in Chapter Requirements Considering the goal described, there are many requirements that should be analyzed and considered. First of all, the company should consider its guidelines and policies. In this area, it s important to analyze all the possible features and constraints that could impact the possibility to go into the cloud. For instance, policies usually also talk about security, from many points of view. The company should be able to understand what are the requirements and constraints related to data security (in terms of privacy, if they are sensitive, if they are considered as confidential or if a potential spread of them could impact the business and company s competitive advantage). Other important requirements are related to application and hardware security, generic security related with possible disasters, as well as the capabilities to prevent and manage them. If policies express the prohibition to shift some part of the business into a cloud environment, of course they must be observed. Moreover, the architectural description of the company should include all the basic characteristics related to the technical, application, data and business levels. The company should have represented all the infrastructure used, the business processes, the data and their features, the objectives of the enterprise, as well as the organizational structure, and all the relations between these terms. In other words, an architectural description of the company needs to be already defined. This description should include all the basic and important features related to the architecture of the company. After having considered the policies and the architectural description, it s important that the company understands what are the main elements to be considered and evaluated before going into the cloud. That is, the company should be able to identify what are the real data that should be protected in the best way, what are the servers that need a security audit, what are the business processes that use sensitive data and so on. In short, there is the need to relate what the policies state with the real description of the company. Moreover, it s also necessary to consider all the laws and regulations affecting the behavior of the company and to map them to the company s description, in the same way as with company s policies.
13 1. Introduction 11 To summarize, one main requirement is given by the presence of laws, regulations and company s policies affecting the shift into a cloud scenario. After that, company s architecture must be described in terms of organizational structure, business processes, data used and infrastructure. The main point of the architectural description is the presence of necessary extensions showing company s features that have to be evaluated before going into the cloud. These features have already been described in the problem description section. If the architectural description used doesn t include these characteristics, the company has, first of all, to identify them. That is, the company has to define what are the guidelines that has to be followed in order to do a good evaluation of its cloud readiness. These guidelines have to include the description of the features and the way they should be evaluated Enterprise Architectures As defined by Tamm, Seddon, Shanks and Reynolds (2011), Enterprise Architecture is the definition and representation of a high-level view of an enterprise s business processes and IT systems, their interrelationships, and the extent to which these processes and systems are shared by different parts of the enterprise. This definition perfectly highlights what is the aim to be achieved with an enterprise architecture: to have an holistic view of the whole company. In this way, it s possible to define the desirable future for the company, and thus what are the enterprise s business processes and IT systems to improve, starting from the current state. Enterprise architecture supports business and IT alignment guiding the change on several levels and helps to set up a roadmap for achieving the company goal. Another interesting definition for enterprise architecture is given by Lankhorst (2009): Enterprise architecture captures the essentials of the business, IT and its evolution. This is a crucial point, indeed, is fundamental to understand what are the essentials of a company to keep as references, in order to develop specific right solutions. Thus, an enterprise architecture allows companies to have a vision always clear of the essentials of the business, allowing, at the same time, for maximal flexibility and adaptivity. The decision to use an enterprise architecture approach is crucial, since as said by Lankhorst (2009), without good architecture, it is difficult to achieve business success. The most important characteristic of an enterprise architecture is that it provides a holistic view of the enterprise. Companies are usually described by using enterprise architecture frameworks. These frameworks allow to represent the architecture of the firm - in terms of different kind of view - and to describe the interrelations between them.
14 1. Introduction 12 A good Enterprise Architecture definition is given by Architectures for Enterprise Integration (2003), in which it is described as a coherent whole of principles, methods and models that are used in the design and realization of the enterprise s organizational structure, business processes, information systems, and infrastructure. Nowaday, there are a dozen reference framework to model an enterprise architecture and the most important, and thus, the most known are the following: Zachman Enterprise Architecture Framework (ZIFA), The Open Group Architecture Framework (TOGAF) and Department of Defense Technical Reference Model (DoD TRM), which cover about two-thirds of all firms. Among all of them, the Zachman Framework has been the first one appeared in academic literature around the early 1990s and today it is considered one of the fundamental framework in the enterprise architecture history. Other frameworks such as DoDAF, MoDAF, and TOGAF are considered framework but are classified as Implementation Frameworks or to be more clear methodologies in combination with a framework. Companies can choose among one of these frameworks choosing the one through which is possible create a synergy of the firm s various capabilities. As written by Tamm, Seddon, Shanks and Reynolds (2011), a recent survey by Infosys claims that around 90 percent of the respondent organisations have an enterprise architecture function and they chose among various professional organisations as CAEAP, GEAO, IFEAD, TOGAF, ZIFA, etc. and government enterpriser architecture initiatives as FEAF, DoDAF, GEA, MoDAF, etc. In addiction, the most large global management consulting firms offer enterprise architecture related services and this suggests that all these organisations around the world spend a considerable amount of time and efforts on enterprise architecture (Tamm, Seddon, Shanks and Reynolds (2011)) Proposed approach The approach proposed in this paper can be divided in three main steps. The first one aims to identify some suggestions, from now on called best practices. These are guidelines that should be considered by each company which is evaluating the possibility to go into the cloud. The goal of these best practices is to touch the most important and critical areas of each company and analyze each of them, trying to highlight the main issues and problems that a company can meet during its cloud computing journey. In this way, companies will be more conscious about the choice they will make. The second step of the approach focuses on giving a knowledge representation for the
15 1. Introduction 13 best practices considered. This work allows to map the guidelines, expressed in natural language, with a more formal way to express these suggestions. The best practices can also be seen as a kind of rule in which each condition correspond to an action. This gives the possibility to express them in many ways, especially with rule-based approaches. To be able to do that, companies should be aware that there is the necessity to define the domain of the rules, that is to model the scenario, the entities involved and the relations between them. The third and last step of the proposed approach provides some hints to extend the knowledge representation, in order to model the best practices in a graphical way. The goal of this step is to allow people to understand what are the important features of the company that should be considered, without checking the best practices or analyzing the defined rules. There will be described how to graphically represent that, for instance, a specific datum requires a high level of security due to privacy concerns, or that specific servers need a security audit once a month, or that the format of specific data is considered as a standard. These extensions are related to different level of the architectural description of the company; this means that some extensions will be added at the data representation level - and then related to the process which uses those specific data - or at the application or technology level. It s important to notice that sometimes it s not possible to be absolutely certain of some company s features. As will be explained later on, even if a company uses a specific standard for virtual machines, there could be the possibility that it won t be able to communicate with the chosen vendor. This could happen since standards can be adapted to company s needs. In this case the graphical description will show the presence of a standard but in the reality it won t be the certainty of the ability to communicate with different vendors. This little explanation needs to show that, in the end, even if the company will extend its architectural description, it s up to the firm to represent the feature in the right way, after a careful and realistic analysis Structure of the paper This paper is organized as follows: in Chapter 2 background concepts of cloud computing and related problems, enterprise architectures and their relation with cloud computing are described. In Chapter 3, the state of the art of the analyzed topic will be presented. In Chapter 4, the main best practices that should be considered to evaluate the possibility to go into the cloud are listed and analyzed. Chapter 5 shows possible extensions of the representations - both in terms of knowledge and graphically - and possible ways to represent Service Level Agreements.
16 2. Background Background 2.1. Introduction In this chapter the aim is to give a general overview about cloud computing, enterprise architecture and the relation between them General Concepts of Cloud Computing In Perez (2002) s opinion, Cloud computing represents the new phase of network evolution as well as the future of the Internet. Cloud computing is a general term within represents a set of hardware and software technologies which allow customers to access, store and process data through resources over the Internet. As written in National Institute of Standards and Technology (2011), cloud computing technologies can be implemented in a wide variety of architectures, under different service and deployment models, and can coexist with other technologies and software design approaches. Gartner (2010), indeed, defines cloud computing as a style of computing where massively scalable IT-related capabilities are provided as a service using Internet technologies to multiple external customers. The cloud computing concept is thus used to describe services provided by Cloud Services Providers. The cloud services models are mainly three, each of which has distinctive characteristics that differentiate them from the traditional IT hosting and thus from services managed in traditonal way. A detailed description of cloud services models follows: Software as a Service Software as a Service, also known with the acronym SaaS, is a software delivery model where a software vendor develops, operates and manages web applications and its associated data, and hosts them centrally in the cloud (OpenCrowd (2011)). The vendors may make these services available, to customers, directly or making use of third-party hosting but focusing only of the quality of their services; without thinking about the infrastructure, capacity, safety or other issues related to where the service is
17 2. Background 15 delivered and what are the performance. This service is extremely easy to use, users may access to web applications and data through a thin client, and to use them is only requires an Internet browser, since they are predominantly solutions web-based. Regarding the costs of this service, it is important to specify the payment methods. It s not necessary that customers buy software licenses to use them, they don t have to pay for the software possession but only to use it. There are different types of fees ranging, from pay-per-use to the fee per person. They use the software through API which are accessible via the web, often as Web Services or REST. As written in OpenCrowd (2011) SaaS has become a common delivery model for most business applications, including accounting, collaboration, Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), invoicing, Human Resource Management (HRM), Content Management (CM) and Service Desk Management (SDM). The SaaS acronym agrees in part with the philosophy of the ASP (Application Service Provider), now in disuse, and indeed, it is seen as an extension of the ASP model Platform as a Service Platform as a Service, also knonw with the acronym PaaS, is a cloud computing service that provide a computing platform and a solution stack as a service (OpenCrowd (2011)). It is possible to locate this type of cloud computing service by idealizing the cloud heirarchy, which is seen as a pyramid divided into three layers and where PaaS is positioned in the middle. This representation makes clear the role of the Platform as a Service that often consumes cloud infrastructure but is also necessary to sustain cloud applications. As written by OpenCrowd (2011) PaaS components allow to develop, test, implement and manage business applications, without considering costs and complexity associated with purchasing, configuring, optimizing and managing of basic hardware and software. These PaaS components can be used to design and develop applications and application services such as team collaboration, web integration, database integration, security and state management. These services can be used as an integrated solution in the web. It is possible to define some different typologies of Platform as a Service: Add-on of development facilities, which allows to modify existing SaaS applications. Stand-alone development environments, which are intended to provide a generalized development environment.
18 2. Background 16 Application delivery-only environments, which are aimed at the distribution that provide services such as security and on-demand scalbility. Open Platform as a Service, which allows the developer to use any programming language, any database, any operating systems, any servers, etc Infrastructure as a Service Infrastructure as a Service, also known as IaaS, is a delivery model where are distributed computing infrastructures as a service, that are typically platform virtualization environments. The virtualisation enables IaaS providers to offer almost unlimited instances of servers to customers and make cost-effective use of the hosting hardware (OpenCrowd (2011)). Infrastructure vendors provide fully outsourced services to support several operations which may be required by customers, allowing them not to purchase servers, software, data storage or network equipment. Customers can select and choose basic software servers for their part of the cloud and then load up their libraries, applications and data. Usually companies configure them by themselves. For cusomers is likely to have considerable IT skills in-house because the infrastructure offered is quite plain. The service provider owns the equipment and is responsible for housing, running and maintaining it. As written in OpenCrowd (2011), companies can use IaaS to quickly build new versions of applications or environments. In this way they don t have to order new hardware and wait for it to arrive and being configured. Another popular use of IaaS is hosting the websites of organisations. This keeps the website and its drain on IT resources away from an internal infrastructure whose primary purpose is to run the business, not the website. In these instances the IaaS provider takes on any worries about monitoring traffic and keeping the website available. The cost of the service is usually based on a per-use basis and on the amount of resources consumed, that generally reflects the level of the activity use(opencrowd (2011)). This cloud service is therefore seen as an evolution of web hosting and virtual private server offerings. After having given a general overview of distinctive characteristics that differentiate the three mainly cloud services models, it is also important to show another classification of the cloud in terms of the location where the cloud is hosted. Cloud compunting, indeed, is also classified in cloud deployment models which represent specific types of cloud environment. The most known types of cloud deployment models, as stated in OpenCrowd (2011), are main three. For clarity, it is fair also to mention a fourth type
19 2. Background 17 of model that is being used in several instances. This deployment model is known as community cloud and it is similar to a public cloud except for the fact that its access is limited to a specific community of cloud consumers. However, herein, will be described the main models Public Cloud Computing A public cloud computing is a cloud environment, also known as external cloud or multitenant cloud (OpenCrowd (2011)). This model essentially represents a cloud environment publically accessible that, generally, provides an IT infrastructure in a third-party physical data center which is owned by a third-party cloud provider. That third-party physical data center, that is hosted at the vendor s premises, can be utilized to deliver services without having to be concerned about the underlying technical complexities. The customer has no visibility over the location of the cloud computing infrastructure. As written in OpenCrowd (2011) essential characteristics of a public cloud typically include homogeneous infrastructure, common policies, shared resources and multitenant, leased or rented infrastructure (operational expenditure cost model), economies of scale. Public clouds can host individual services or collections of services, allowing for the deployment of service compositions and even entire service inventories Private Cloud Computing A private cloud computing is a cloud environment, also known as internal cloud, corporate cloud or on-premise cloud. This cloud environment is a proprietary computing architecture that provides hosted services to a limited number of people behind a firewall and is not shared with other organisations (OpenCrowd (2011)). A private cloud intentionally limits the access to its resources to service consumers that belong to the same organization that owns the cloud. In other words, the infrastructure that is managed and operated by one organization is primarily used to maintain a consistent level of control over security, privacy, and governance. Advances in virtualization and distributed computing have allowed corporate network and datacenter administrators to effectively become service providers that meet the needs of their customers within the corporation. A private cloud is expensive but is considered more secure than public clouds. It may be externally hosted ones as well as in premise hosted clouds. Essential characteristics of a private cloud typically include heterogeneous infrastructure, customized and tailored policies, dedicated resources, in-house infrastructure (capital expenditure cost model), end-to-end control.
20 2. Background Hybrid Cloud Computing A hybrid cloud is a cloud environment composed of at least one private cloud and at least one public cloud. Typically this cloud environment can be offered in two different ways: a vendor has a private cloud and forms a partnership with a public cloud provider, a public cloud provider forms a partnership with a vendor that provides private cloud platforms. However it is an environment in which an organization provides and manages some resources in-house (e.g. some critical, secure applications) and has other resources are provided externally (e.g. not-critical applications). For example, an organization might use a public cloud service for archived data but continue to maintain in-house storage for operational customer data. Ideally, the hybrid approach allows a business to take advantage of the scalability and cost-effectiveness that a public cloud computing environment offers without exposing mission-critical applications and data to third-party vulnerabilities. This type of hybrid cloud is also referred to as hybrid IT (OpenCrowd (2011)) Enterprise Architectures Enterprise architecture was born as an information technology discipline. As stated by?, initially the purpose of enterprise architectures was to promote the strategic development of an organization s IT systems through the modelling of the organization, as well as the aligning of IT purchasing and development with business priorities. In recent years, however, in the enterprise architecture field there have been some changes easily identified in the definition of enterprise architecture given by Gartner: Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise s future state and enable its evolution.. As evidenced by Gartner s definition, enterprise architecture has expanded beyond the IT domain and enterprise architects are increasingly taking on broader roles relating to organisational strategy and change management. This view of enterprise architecture is a more holistic view and works across all levels of the organisation, connecting business goals with the organisational data, applications and technology that facilitate them. As stated by Marc Lankhorst (2007), this discipline is commonly considered to have its
21 2. Background 19 birth in an academic article by John Zachman, titled A Framework for Information Systems Architecture,, published in 1987 by the research-oriented IBM Systems Journal. The challenge of Zachman was to manage the complexity of increasingly distributed system. Indeed, as Zachman explains in the article above mentioned, the cost involved and the success of the business depending increasingly on its information systems, require a disciplined approach to the management of those systems. The growth of the discipline, however, took place mainly in the practitioners cradle Marc Lankhorst (2007). Over the years, the interest in the discipline of enterprise architecture has grown more and more and there has been steady academic work that interested this area. Anyway, a research on enterprise architecture has been taking place in isolated communities by different communities of researchers, each of which had different experiences, problems and ideas related to enterprise architecture and therefore are born several trends. Practitioners of enterprise architecture are also called enterprise architects and their goal is to deliver an architecture that supports the most efficient and secure IT environment and meets the business needs of a company. In short, they deal to link the business mission, strategy, and processes of an organization to its IT strategy. They document all these, using multiple architectural models or views that show how the current and future needs of an organization will be met in an efficient, sustainable, agile, and adaptable way. As already mentioned above, there were born several communities of researchers and there were created various methods to describe the structure and dynamics of a company. These methods, or frameworks, also describe step by step procedures that can be undertaken to construct both the architecture and the deliverables produced at each stage. Most of these methods involve procedures that take account of the four common architectural areas of domains: business, data, applications and technology. These architectural domains contain components within an organization, which are interrelated in a certain way, in order to address all possible requirements of all system stakeholders, like people, departments and functions. Indeed, frameworks were created to be used to organize enterprise architecture into different views, meaningful for the system stakeholders. These enterprise architecture frameworks are often composed by different set of things, some of which are highly specialized. Others, instead, are often standardized for defence and commercial systems. Therefore, it is through all these methods that enterprise architects were able to produce taxonomies, diagrams, documents and models usable by all different stakeholders. Enterprise architects call a complete collection of taxonomies, diagrams, documents and models with the name artifacts, and they consider them the best way to describe a company and to give to it a complete enterprise level architectural descripc 2012 School of Business, FHNW, Institute for Information Systems, H. Wache
22 2. Background 20 tion. Artifacts can describe: the logical organization of business functions, business capabilities, business processes, people organization, information resources, business systems, software applications, computing capabilities, information exchange and communications infrastructure within the enterprise. It is throught the correct use of a set of these artifacts, that an enterprise architecture can have an optimal IT planning, architecting and an enhanced decision-making. As stated by Jarvis (2003) each individual model in an enterprise architecture is arranged in a logical way and provides an ever-increasing level of detail about the enterprise: its objectives and goals; its processes and organization; its systems and data; the technology used and any other relevant area of interest. An enterprise architecture is not so easy to build and apply on each different company, but once in place it can have great power to resolve issues and provide insight into complex, confusing situations Jarvis (2003). Always according to Jarvis (2003), it is possible to list some points in order to have an idea of what are the purposes which want to be achieved by choosing an enterprise architecture framework to support the company: to provide a mechanism to evaluate business and technological change; to offer a vehicle for medium to long term business and technical planning; to link future aims with current achievements; to create a dynamic portfolio of projects i.e. scoped and bounded, sequenced, ready for development, not just IT projects. An enterprise architecture brings many considerable benefits and executives can have a huge help from it, for proposing and testing strategies for the company development, but also to plan and for reacting in an easy way to business changes Main problems in Cloud Computing Even more companies, today, are embracing cloud computing as a way to lower investment costs, greater the Retrun On Investment and increased efficiency. But many others companies fear the cloud because they don t want to trust their data to a vendor or simply they don t want to put them in an external place they can not totally control. Indeed, cloud computing is simply sharing or storage, by users, of data or applications on servers owned or managed by third parties, which are accessed via the internet.
23 2. Background 21 But this could become a problem when information is scattered in centers with different legal regimes, where often the laws are inadequate and inappropriate. People still think in terms of physical servers well located but it is not trivial to manage data privacy in a cloud environment. It is possible that the cloud infrastructure is used in a malicious way to conduct an attack. The lack of physical control and the sharing of resources can lead to problems of industrial espionage, loss or manipulation of data, as well as to the exposure of data to third parties. In addition, the security of APIs exposed by cloud services is critical because the security model of them must be properly designed to prevent them being exploited for attacks. It can be easily said that the cloud computing includes all the traditional information security risks but also some additional risks. The most relevant ones which should not be undervalued and on which we want to focus herein are related to the portability and the privacy Portability The term portability is used in cloud computing context most of the time in regard to an application. It is also called cloud portability and technically, as explained by Continental Automated Buildings Association (2004), it is used to ensure that an application has a common method of programmatic interaction to the underlying and services. In other words, it is the capability to run applications and its associated data, between one cloud provider and another with minimal disruption. But it is important to highlight that is also the capability to run applications and data between different cloud environments: i.e. from public to private. The problem is that cloud service providers are multiplying in numbers everyday and most of them use its own proprietary API s. This means that if a company, which initially has chosen a cloud provider, in the future would need to switch to another cloud provider, probably it will have problems. As stated in Cloud Security Alliance (2009) the necessity to move from one cloud service provider from another can born from different reasons which will be listed hereafter: high increase of costs; the provider will stop to operate at all; the provider will not provide some of the services being used, strong decrease of service quality. As discussed in Cloud Security Alliance (2009), it is possible to go in more detail, describing possible problems for each kind of services. Regarding Software as a Service, a possible issue may occur when old software applications must be changed with
24 2. Background 22 a new one. In this case it is necessary to analyze the features of the new software application because it may not have an adequate security level, which should at least match the old one. Regarding Platform as a Service, instead, a possible problem may occur when an application must necessarily be modified in order to allow the portability. In this case, the problem could involve the number of necessary changes, and which are not always possible. Finally, regarding Infrastructure as a Service some problems could occur when applications and its associated data must migrate from a cloud environment to another. In this case the problem can regard conditions which affect the new cloud environment and which may not be appropriate to run those applications and data Privacy Privacy is a critical risk factor that affects, practically, each kind of company. There are, however, special cases in which companies operate in some critical areas and data can not migrate outside the company sphere. They are, obviously, sensitive data, particularly relevant for the company s business, such as strategic data or industrial secrets. But also other kind of data may also be considered sensitive data. Personal customers information, for example, are extremely important for an individual practitioner, who may be very loath to deposit company s data to an external service. Choosing a cloud provider means to trust entirely to his ability. It must be, therefore, a provider extremely professional in the care of the infrastructure and implementation of all best practices in security. Usually, a problem concerning privacy can occur because of data location. As stated by Pearson (2009), indeed, private information of each company is stored in databases, where it s collected with private information of several other companies. Then, another issue that should not be underestimated, as pointed out by Gartner: companies often do not known where their data are exactly. Sometimes it is neither clear in which country they are stored, and thus, in what jurisdiction they are (Gartner). This can be a problem whether databases and servers are located in countries with different privacy laws considered not safe enough and where data may not be safe from attacks. Anyway, service provider must ensure by contract the policy used for privacy. They are primarly responsable, and thus, must always be able to ensure the safety of the service provided. Companies, in order to avoid privacy risks due to different privacy laws, should consider carefully the terms and conditions of the service provider.
25 2. Background Interrelation between Cloud Computing and Enterprise Architectures After having given the necessary knowledge in the preceding paragraphs, to understand what cloud computing and enterprise architecture are, in this section we want to complete the general overview talking about the interrelation between them. As discussed above and as stated also by Linthicum (2010), an enterprise architecture is a strategic information asset base, which defines the mission, the information necessary to perform the mission, the technology necessary to perform the mission, and the transitional processes for implementing new technologies, in response to the changing mission needs. An enterpise architecture characterizes and models the enterprise throught a set of interrelated layers or views: strategy, business, data, applications, and technology (or infrastructure). A company which decides to move into the cloud must have a mature and well formed understanding of the enterprise architecture on which is based and, thus, a clear view of components which concern it (strategy, business, data, applications and technology). This understanding is absolutely necessary for the enterprise to make meaningful decisions related to cloud computing. As exemplified by Linthicum (2010), indeed, it is through a good knowledge of the own company that is possible to assess whether a move to the cloud is advantageous, what services most lend themselves to a cloud deployment, and what cloud deployment model (private or public) makes the most sense. According to Linthicum (2010) it is possible to distinguish three key roles for enterprise architecture in facilitating cloud computing strategy and planning: front-end decision support, cloud implementation planning support and enterprise context. Front-end decision support. An organization s enterprise architecture should inform decisions about the desirability of a move to a cloud environment, what services should move to the cloud, and the appropriate deployment models. Existing business processes, services and resources should be analyzed through the lens of cloud characteristics and quality dimensions, such as elasticity, reliability, and security. Cloud implementation planning support. During the period of transition, an enterprise architecture provides the current inventory of services and the roadmap to which services are being deployed into what clouds. As new business needs emerge, the EA provides solution architects with a view of what has been deployed in the cloud already and what is planned for future deployment. Enterprise context.
26 2. Background 24 Sharing and reuse of services and resources, have been primary objectives of enterprise architecture. In the context of a cloud strategy, enterprise architecture provides a critical enterprise view to ensure cloud decisions are optimized at the enterprise level and independent decisions on cloud-based point solutions are viewed in a broader context.
27 3. State of the Art State of the Art A literature review has been done in order to find out the main issues of this topic and already proposed approaches. Unfortunately, there are not yet so many papers and articles about it. According to Ebneter et al. (2010), first of all it s necessary to define a set of best practices which capture all the knowledge. These best practices can be then used to compare the configuration and the description of the enterprise. Ebneter et al. (2010) propose to use a graphical model to show the main features of the enterprise in a way that they can be understood also by business people. In particular, these graphical models can be used to extend the description of business processes but also the IT infrastructure and the organizational structure. Unfortunately, this work is not yet completed. It just gives some general hints on how to proceed but nothing more. There are no specific information about what best practices should be considered, neither about the knowledge or graphical representations. Thorn (2011) stated that the enterprise architecture description should be well defined in order to be able to move into the cloud. Again, the main aspects that should be considered for the evaluation are related to the level of interoperability requested and defined, the needed level of security, the presence of applications proprietary interfaces, problems related to new products and services (e.g. secrecy of the not yet patented process). Thorn (2011) focuses especially on the usage of TOGAF9 in order to guarantee the fit between the enterprise architecture description and cloud computing. This approach could be a little binding since it s specifically oriented to the use of a particular enterprise architecture framework. This means that not all the companies can be able to use it, since they could need some modification of the enterprise architecture description in order to use TOGAF9 and the approach proposed in Thorn (2011). Moreover, Thorn (2011) doesn t show a set of best practices important to be considered, that is a fundamental part of the enterprise architecture description optimization. Therefore, also this paper doesn t give many clues on how to proceed. Best practices are not considered at all and the approach used is for a specific enterprise architecture framework. Possible ways to extend the knowledge or the graphics are not included in the work. Delaquis & Philbin (2011) also agree that a good enterprise architecture description is critical for the evaluation of the readiness to go into the cloud. In their opinion, the main
28 3. State of the Art 26 questions that a company should ask itself concern the ability to emulate its processes in a cloud scenario, the level of security the cloud provider is able to offer and if the security mechanisms are compatible with the ones of other cloud computing vendors. This work gives generic hints on the most important issues of cloud computing and the most important areas of the best practices that should be considered. Except that, there is no linkage between cloud computing and enterprise architectures and no suggestions on how to extend the architectural description of the companies. Many best practices can be found in Velte et al. (2009), Cloud Security Alliance (2009), Federal Office for Information Security (2011) and National Institute of Standards and Technology (2011). After having analyzed these publications, it s possible to understand that the main areas of interest are application security and encryption, governance and risk management, incident management, portability and interoperability, privacy, security, as well as disaster recovery. Anyway, these papers are useful only for the identification of the main areas of focus and the main issues that should be considered in each area. The current state of the art doesn t satisfy our requirements: it was not possible to find out already existing approaches that allow to extend the enterprise architecture description in order to evaluate companies readiness to go into the cloud. Some best practices have been found out. They will be considered and analyzed in this work, in order to describe the fundamental cloud computing related issues to consider, when describing an enterprise architecture. There was not possible to find how to relate these recommendations with the concrete architectural description, neither in terms of knowledge nor in a graphical way. Nevertheless, possible solutions to extend the graphic representation is by using stereotypes, as proposed in Open Group ( ), or by using enterprise architecture modeling languages, as can be deducted in Ebneter et al. (2010). For these reasons, how to extend the architectural description of a company, in order to evaluate its readiness to go into the cloud, still remains an open question.
29 4. Best Practices Best Practices In this chapter there will be described some guidelines and recommendations that should be followed, in order to evaluate if the architectural representation of the company that desires to go into the cloud is good enough or if it needs some extensions. These recommendations are organized in different groups: application security and encryption, governance and risk management, incident management, portability and virtualization, privacy, security and disaster recovery, as well as service availability Application security and encryption Applications running in cloud systems are affected by and can affect many features. As written in Cloud Security Alliance (2009), the main factors are related with: Dependencies with other systems: sometimes the dependencies with other systems can be really strong and can also involve external service providers. This scenario leads to the need to change the architecture of the application in order to guarantee application security. Software development process: if the application will run in a cloud environment, then all the phases of the software development life cycle are affected. This implies that the identification of the requirements, design, implementation, verification and maintenance should be done considering the main problems that can occur in a cloud environment. Vulnerabilities: this factor includes not just the vulnerabilities related with the applications but also possible vulnerabilities deriving from the dependencies and relations with other machines operating in the cloud environment. The other aspect of security is related with the data used and stored inside the cloud environment. As written in Velte, Velte & Elsenpeter (2009), if you have to work with sensitive data, a cloud environment could not be the safest place to store them. Anyway, one possible way to protect them is using encryption. According to Velte, Velte & Elsenpeter (2009), usually it s better to choose a paid encryption service in opposition to one based on advertising. The main reason is that is
30 4. Best Practices 28 more likely that in the last type of service, data are analyzed and assembled through users profiles and then used for marketing purposes. In general, it s better to store data in the most secure place, even if it means to store them in house and waiting for a better external service. As stated by Cloud Security Alliance (2009), cloud customers want that their cloud providers encrypt their data (sensitive and normal ones) in order to be, more or less guarded, if data are stolen or lost. Moreover, in some cases, there are also laws and regulations that oblige cloud providers to use a strong data encryption system. It s important to notice that sometimes, laws treat lost encrypted data as if they are not lost at all, Cloud Security Alliance (2009). For these reasons, the choice of the provider will be done considering, among other criteria, the kind of encryption offered and how much strong it is. Recommendations Some recommendations concerning application security and encryption can be listed, considering what it s written in Cloud Security Alliance (2009): 1. Communications inter-host should be secure. 2. The management of application credentials is critic: they should be protected and secured. 3. It should be paid attention on the management of application files, and related locations, used for logging and debugging. 4. Cloud providers should give the possibility to the customers to check the security of application by performing remote vulnerability assessment and application vulnerability assessment. 5. It s important to use encryption to separate the storage and the usage of data. 6. The chosen encryption system should conform to the existing industry and government standards. 7. Understand how the cloud provider manages encryption keys and if it uses the same key for all its customers. Particular attention should be paid on how the key life cycle is conducted, that is how the key is created, stored, used, recovered and deleted. 8. Separating the key management from the hosting of data, by using different cloud providers, protects the customer and the cloud provider.
31 4. Best Practices Keys used to encrypt data must themselves be protected when they are stored, in transit or backed-up. 10. Cloud provider should give the possibility to limit the access of stored keys to the entities that need them. 11. Cloud provider should offer a recovery system in the case that encryption keys are lost. 12. Check if the data are encrypted also during the transit inside the cloud provider s network. Cloud provider s network is more secure than the Internet but, anyway, it s shared between different customers. 13. It s possible that in IaaS scenario, also virtual machines files and temporary data need to be encrypted Governance and risk management According to National Institute of Standards and Technology (2011), governance is related to the control of policies, procedures and standards of application development. Moreover, it deals with activities related to deployed services like the design, implementation, testing and monitoring. The identification of the suitable organizational structure, but also of processes and controls, are the main issues in order to have an effective risk management and information security governance, as stated in Cloud Security Alliance (2009). Recommendations Some recommendations concerning governance and risk management can be listed, considering what it s written by Cloud Security Alliance (2009) and National Institute of Standards and Technology (2011): 1. To guarantee that fixed requirements are met, it s necessary to perform security controls, assessment and audits. Audits are important to determine how data are stored and used, as well as how they are secured. 2. The cloud computing provider and the customer should collaborate and develop a good information security governance, in order to achieve selected goals and requirements that support the mission of the company and its information security plan.
32 4. Best Practices Assessments of information security governance structure and processes and security controls should be planned and executed. The main criteria of the assessment could be the maturity and consistency of the information security management processes. 4. Security managers and responsible people should be involved during the settlement of Service Level Agreements in order to ensure that security requirements are enforceable. 5. In general, Service Level Agreements should include documented and demonstrable security metrics and standards. 6. The risk management procedure should consider the identification and evaluations of assets, the identification and, consequently, the analysis of possible threats and vulnerabilities and the strength of the impact on the assets. Possible scenarios should be evaluated and different risk treatment plans should be analyzed and developed. 7. If the cloud computing service provider doesn t offer effective risk management processes and practices, the customer should consider the possibility to use his own abilities in order to close the risk management gap. 8. In order to manage risks, it s important to pay attention to the roles and the related responsibilities within the risk department Incident management Incident response involves an organized method for dealing with the consequences of an attack against the security of a computer system National Institute of Standards and Technology (2011). To guarantee a certain level of security and privacy and to react to an incident, the collaboration between cloud provider and customer is critical. According to Cloud Security Alliance (2009), one of the main problems for cloud customers is that, sometimes, applications running in the cloud environment are not really good in terms of data integrity and security. Consequently, these applications have a certain degree of vulnerability which can trigger security incidents. It s important to notice that the incident response strategy is different between cloud providers. Moreover, the management of application data and access, as well as the related regulatory requirements, depend on the data geographic location (different regulations among different countries) Cloud Security Alliance (2009). According to Nac 2012 School of Business, FHNW, Institute for Information Systems, H. Wache
33 4. Best Practices 31 tional Institute of Standards and Technology (2011), depending on where the data are located, there is the possibility that an investigation could be banned. Recommendations Some recommendations concerning incident management can be listed, considering what it s written by Cloud Security Alliance (2009) and National Institute of Standards and Technology (2011): 1. One of the first things that a cloud customer should do before the service is deployed, is to explicitly define what is considered an incident and what a mere event. 2. Before signing a contract, the available and used procedures for incident response should be understood and, if possible, negotiated. 3. It s important for the cloud customer to understand and find out what are the tools used to detect incidents, to ensure the compatibility with the existing systems. 4. As a general rule, applications and systems design and security should be good. If they lack in these features, even if the incident response capabilities are really good, there could be problems to face the incident. 5. It s important to consider the ability of the cloud provider to restore a previous state of the system. Sometimes, the remediation process need to go back to twelve months in order to restore a good configuration of the system. 6. If there are data labeled as private, then they have to be encrypted in order to reduce the consequences of a possible incident. 7. A cloud provider should offer, at least, systems and tools, for responding to incidents, reflecting the state of the art (e.g. firewalls, proxies, application logging tools). 8. The future geographical location of the data should be considered in order to understand possible problems related to the impossibility to conduct incident investigations and different ways to manage application data and access due to existing regulations Portability and interoperability According to Federal Office for Information Security (2011), cloud computing portability can be considered as the independence of platforms, that is the capability of running in
34 4. Best Practices 32 different cloud computing environments. Cloud customers should have clearly in mind that, in the future, there could be the necessity to switch cloud provider. Some of the reasons, according to Cloud Security Alliance (2009), are: a high increase in costs, the provider won t operate anymore at all or won t provide some of the services being used, as well as a strong decrease of service quality. It s important to keep in mind that if there is a lack in the usage of standards, then the portability operations could be difficult. It s possible to describe in short the main issues of cloud portability, considering the different types of services, as written by Cloud Security Alliance (2009): Software as a Service: old software applications will be changed with new ones. In this case it s important to ensure that the new application security level is at least as the level provided by the previous service provider. Moreover, attention should be paid to ensure the success of data migration from one provider to the other. Platform as a Service: it s likely that some application modifications will be necessary in order to allow portability. The main goal is to reduce the number of modifications needed and, at the same time, to ensure a certain level of security. Infrastructure as a Service: application and data will be migrated in the new cloud environment and they should be able to run in the new scenario. According to Federal Office for Information Security (2011), cloud interoperability is related to the situation in which two or more cloud environment are working together. There is no need to make any kind of agreements between the different platforms but, it s important that the interoperability scenario should be based on the usage of standard formats. At the current time, there are many standards that allow to reduce portability and interoperability problems. As identified by Federal Office for Information Security (2011), some of them are: the Open Cloud Computing Interface created by the Open Grid Forum, the vcloud API by VMware and the Open Virtualization Format. Recommendations Some recommendations concerning cloud portability and interoperability can be listed, considering what it s written by Cloud Security Alliance (2009) and Federal Office for Information Security (2011): 1. Before starting the portability operations, it s important to understand the amount of data that should be transferred in order to shorten the transition period. Somec 2012 School of Business, FHNW, Institute for Information Systems, H. Wache
35 4. Best Practices 33 times, it s faster to send physically hard drives instead of electronically transferring data. 2. The security architecture of the system and components should be documented in order to simplify the portability process. 3. It s important to know and understand how virtual machines configurations can be captured and transferred to the new cloud environment, especially if it uses different technologies. Moreover, virtual machines extensions specific for a certain environment should be eliminated. Portability should be enabled by using, for instance, the Open Virtualization Format. 4. Identify and understand any kind of dependencies related to applications and data. Moreover, the presence of interfaces, APIs or functions that are not compatible with the new cloud provider should be determined. 5. If possible, standards applicable to virtual machines, applications and data should be used in order to simplify the portability process and to avoid vendor lock-in scenarios. 6. Identify the best tool to guarantee security of data when they are transferred and backed up. 7. Identify and document, if present, the application components and features that are specifically related to the current cloud provider. Then, try to develop some interfaces or abstraction mechanisms, in order to limit the access to the specific modules and components. 8. It s important to know how the verification of the correct execution of applications transfer is executed. Moreover, the responsibilities about testing for the cloud providers should be documented and well explained and delimited. 9. Periodically data should be backed up by using a standard format. 10. If there are customized tools, it s important to understand that, to allow portability, they have to be redesigned and implemented again. A possible alternative is that the new cloud provider provides these tools Privacy According to Pearson (2009), privacy is one of the main concerns of companies when considering the possibility to go into the cloud. Customers data, which are often sensitive or related to company s private information, are usually stored into databases
36 4. Best Practices 34 containing also data of other customers. For this reason, as stated by Pearson (2009), the focus in cloud computing is designing cloud services in a way to decrease the risk related to privacy and to guarantee compliance with law. Pearson (2009) has grouped this personal information in different categories: 1. Personally identifiable information: which includes all the information that can directly identify a person or that can be used, in addition to other information, for the same purpose. 2. Sensitive information: which includes all the information related to job performance, religion, health status, relationship status, sexual orientation. 3. Information categorized as sensitive: which includes video of cameras in open places. 4. Usage data: which includes all the information gathered by the usage of computer devices and information related to habits for digital materials. 5. Unique device identities: which includes other information like IP addresses, hardware identifiers or RFID tags identifiers. Recommendations: Some recommendations concerning cloud privacy can be listed, considering what it s written by Centers for Medicare and Medicaid Services (2011) and Gellman & Dixon (2009): 1. If the cloud service provider can change the terms of service unilaterally, that is without an expressing agreement with the customer, the company should think carefully about choosing it. 2. If possible, choose a cloud service provider which offers standards for confidentiality and integrity of data. 3. If the cloud service provider will own the data even after the deletion or transfer to another provider, think carefully about choosing it. 4. It s important to understand and to consider if the backup copies of data will be sent to the customer, once the contract ends or if the provider goes into bankruptcy. 5. It s important that a procedure to handle breaches is carefully defined.
37 4. Best Practices Attention should be paid in order to understand if the cloud provider has some rights to use or make public the data stored in the cloud. 7. If there are some data that should not be seen by competitors, think twice about storing them into the cloud. 8. Companies should check if they can store specific data into the cloud, that is if it s permitted by the law and regulations Security and disaster recovery According to Cloud Security Alliance (2009), another challenge in cloud computing is to identify possible risks and put in practice all the actions to prevent them like physical security, business continuity planning and disaster recovery. To guarantee a certain level of security, it s necessary to plan security incidents and the handling of them in advance, as described by Federal Office for Information Security (2011). Moreover, cloud services should be monitored everytime, 24/7. As stated by Somashekar (2010), disaster recovery plans can ensure that the data are backed up but also virtual machines configurations can be included. It s also important to notice that collaborations between cloud service providers, allow data replication between them. Recommendations Some recommendations concerning security and disaster recovery can be listed, considering what it s written by Cloud Security Alliance (2009) and Federal Office for Information Security (2011): 1. Cloud customers should consider that the centralization of data could lead to the risk of an insider abuse, from the service provider perspective. 2. Cloud customers should analyze periodically the disaster recovery plans and business continuity plans of the service provider. 3. It s important to identify the interdependencies in the cloud provider physical infrastructure. 4. Cloud customers should understand if the service providers adheres to any security industry standards.
38 4. Best Practices Cloud providers should have a business continuity management system based on existing standards, in order to react rapidly when emergencies occur and to restore critical business processes. 6. Cloud providers should be able to give evidence regarding the changes made to the service, the time when they have been made and by whom by logging all the activities. 7. Cloud providers should make regular business continuity management exercises in order to find out possible inconsistencies in the crisis plan and to train effectively in case of emergency Service availability National Institute of Standards and Technology (2011) defines the availability as the degree to which applications and resources are accessible or usable. There are many threats that can influence the availability, temporarily or permanently. Anyway, the outcome of these threats is common, since they can have effect on the mission of the company and its business. In some cases, especially in the presence of prolonged or permanent outages, the company could have serious problems related with losses or even bankruptcy. As described by National Institute of Standards and Technology (2011), service availability is related to its degree of reliability. The reliability is usually expressed in percentage and the hours of downtime can be easily determined. All this information should be included in the Service Level Agreement. Nevertheless, there are some cases in which service availability is threatened by intentional attacks, like Denial of Service, or by the lack of the needed resources. As an example, consider the scenario in which a company has been outsourced a web service and the resources needed to run it. Considering a scenario in which the company is a university, the purpose of the web service is to gather information - by using an application form - about students and their preferences for the courses they would like to attend during the next semester. The data of the students should be available in a specific date, leading to the necessity to set a deadline to fill in the form. It s possible to hypothesize that there will be a heavy workload during the days immediately before the deadline. This situation could threaten the availability of the service (in this case the availability of the web service and related resources to gather information) if the cloud vendor is not able to provide the amount of resources needed.
39 4. Best Practices 37 Recommendations Some recommendations concerning service availability can be listed, considering what it s written by National Institute of Standards and Technology (2011) and Buck & Hanf (2010). Moreover, some hypothesis are included. 1. The contingency planning of the company should include the degree of reliability of the system and services and the capabilities for backup and recovery. 2. The SLA should include the provider of the service, the customer and all the related information. 3. The SLA should define the time period of validity of the service. 4. The SLA should describe the services and capabilities offered and the metrics used to evaluate their performance. 5. The SLA should describe the degree of reliability of the system, the time during which the services are guaranteed and the accepted downtime due, for instance, to maintenance. 6. The SLA should describe how the vendor will manage possible outages and the related response time. 7. The SLA should define the penalties for the vendor when the service is not provided. 8. The SLA should define customer and vendor responsibilities. 9. The SLA should define the costs of the service 10. Companies dealing with real-time processes should analyze how risky is to go into the cloud. This could be made considering the impact on profit if the system or service is unavailable. Other alternatives could be the presence of a deadline and if many people have to access a specific service. 11. Companies dealing with real-time processes should define a strong SLA in order to have a security in the case of service unavailability.
40 5. Representations Extensions Representations Extensions As already explained in the previous chapters, to be able to evaluate if a company is ready to go into the cloud, enterprise architecture frameworks need to be extended. They need extensions in order to fully describe all the best practices described in Chapter 4 and to analyze all the relevant concepts related to the shift of the activities and infrastructure in a cloud environment. The extensions needed can be grouped in two main categories: graphical extensions to allow to understand the requirements in an easy way - just looking at the architectural description - and knowledge extensions to represent the semantic of the extension and to relate the best practices to the graphical part. It s also important to consider how to represent Service Level Agreements in order to include them in the architectural description of the company Graphical representations Graphical representations are used to highlight particular features of the architectural description of the company. Some matrices will be proposed and their meaning explained, in order to facilitate the understanding of the cloud potential of a company. As already stated in Chapter 2, enterprise architecture is a holistic view of the enterprise which makes easier to understand the architecture of an enterprise. To help companies to know what is needed to define the holistic view of the company, enterprise architects have created in the last 25 years several enterprise architecture framework. The most important approaches are mainly four: the Zachman Framework for Enterprise Architectures, The Open Group Architecture Framework (TOGAF), the Federal Enterprise Architecture Framework (FEAF), and Gartner (formerly, the Meta Framework). As already mentioned, the goal is to build an extension from a generic framework, to allow companies to understand what are the critical points to consider whether they want to go into the cloud. The enterprise architecture framework that has been taken into account for the extension is a generic enterprise architecture framework. A first representation of the extension is proposed in Figure 5.1 through a three-dimensional
41 5. Representations Extensions 39 pyramid and it shows two facades. The first facade is composed by five elements that usually characterize the structure of a generic enterprise architecture. In this side the five elements are represented as building blocks that describe the whole enterprise and they allow an high-level view of the system they describe. From the top it is possible to distinguish the following layers: Strategy, Business, Data, Application and Technology of the enterprise. In the second facade, are respresented the seven areas of interest defined in Chapter 4, which are of fundamental importance for companies that want to move into the cloud. On this side, the blocks are organized vertically, because each area of interest can affect each one of the five elements that characterize the structure of the enterprise. Therefore, it is possible to distinguish the following layers: Application Security and Encryption, Governance and Risk Management, Incident Management, Portability and Interoperability, Security and Disaster Recovery, Privacy and Service Availability. Figure 5.1.: Pyramid representation of the Enterprise Architecture Framework Extended The following step will help the understanding of the extension of the enterprise architecture framework. In the following sections, indeed, each area identified in Chapter 4 will be analyzed individually. Some matrices will be proposed for each area of interest hereafter and their meaning will be explained, in order to facilitate the understanding of the cloud potential of a comc 2012 School of Business, FHNW, Institute for Information Systems, H. Wache
42 5. Representations Extensions 40 pany. For each area, the recommendations defined in the Chapter 4 are considered. The best practices and the layers of the enterprise architecture are used in order to produce a matrix. The aim of the martrix is to express, for each recommendation considered, what are the layers affected. The presence of a possible danger is shown by using a yellow warning symbol Domains and generic framework The graphical representations shown in the following sub-sections, aim to highlight what are the levels of the enterprise architecture framework of a company that want to go into the cloud, that must be carefully evaluated considering one by one all the areas of interest. In Chapter 4 some best practices and respective recommendations have been described for each domain. These recommendations have been, then, taken in account to extend the architectural representation. The matrices proposed are composed on the ordinate axis by the five layers that characterize the structure of a generic enterprise architecture framework and on the abscissa axis by the most significant recommendations. Each recommendation can involve one or more layers. In order to highlight the importance of the recommendations and, thus, the possibility that a danger might occur at that level, the intersection of the two layers is emphasized by a particular yellow symbol of warning. Application security and encryption After a careful analysis, we selected the most significant recommendations for the application security and encryption area which are related to possible issues against which a company may incur. These are the number 2, 5, 6, 9, 12 and 13. They deal in particular with the management of credential and encryption keys, the need of encryption for particular data and files, as well as the compliance to existing encryption standards. As can be seen in the matrix in Figure 5.2, the first recommendation useful is the number 2: The management of application credentials is critic: they should be protected and secured and involves the Application layer. The recommendations number 5 It is important to use encryption to separate the storage and the usage of data, number 12 Check if the data are encrypted also during
43 5. Representations Extensions 41 Figure 5.2.: Graphical representation for application security and encryption domain the transit inside the cloud provider s network. Cloud provider s network is more secure than the Internet but, anyway, it s shared between different customers and number 13 It s possible that in IaaS scenario, also virtual machines files and temporary data need to be encrypted involve, instead, the Data layer. The recommentations number 6 The chosen encryption system should conform to the existing industry and government standards and number 9 Keys used to encrypt data must themselves be protected when they are stored, in transit or backed-up in the end, involve the Strategy Layer. Governance and risk management After a careful analysis, the most significant recommendations for the governance and risk management area, related to possible issues against which a company may incur are the number 1 and 6. They deal in particular with activities that should be executed no matter what is the cloud provider. As is possible to see in the matrix in Figure 5.3, the first recommendation useful is the number 1 To guarantee that fixed requirements are met, it s necessary to perform security controls, assessment and audits. Audits are important to determine how data are stored and used and, most important, how they are secured and involves the Data layer. The second recommendation useful is the number 6 The risk management procedure should consider the identification and evaluations of assets, the identification and, consequently, the analysis of possible threats and vulnerabilities and the strength of the
44 5. Representations Extensions 42 Figure 5.3.: Graphical representation for governance and risk management domain impact on the assets. Possible scenarios should be evaluated and different risk treatment plans should be analyzed and developed and it involves, instead, the Strategy and the Technology layers. Incident management A careful analysis, led to the choice of determined recommendations deemed the most significants in order to understand possible issues against which a company may incur. In this area the most significant recommendations are the number 1 and 6. Both of them deal of the description of the enterprise architecture and of the important features related to incidents and ways to minimize incidents consequences. As is possible to see in the matrix in Figure 5.4, the first recommendation useful is the number 1 One of the first things that a cloud customer should do before the service is deployed, is to explicitly define what is considered an incident and what a mere event and involves the Strategy layer. The second recommendation useful is the number 6 If there are data labeled as private, then they have to be encrypted in order to reduce the consequences of a possible incident and it involves, instead, the Data layer. Portability and interoperability A careful analysis, led to the choice of determined recommendations deemed the most significants in order to understand possible issues against which a company may incur.
45 5. Representations Extensions 43 Figure 5.4.: Graphical representation for incident management domain This time, the most significant recommendations have been considered are the number 4, 6 and 10. They mainly deal with the applications interfaces and data formats used, as well as security measures for transferring data and for storing them. As is possible to see in the matrix in Figure 5.5, the first recommendation useful is the Figure 5.5.: Graphical representation for portability and interoperability domain number 4 Identify and understand any kind of dependencies related to applications and data. Moreover, the presence of interfaces, APIs or functions that are not compatible with the new cloud provider should be determined and this time, involves two levels: both Data and Application layer.
46 5. Representations Extensions 44 The second recommendation useful is the number 6 Identify the best tool to guarantee security of data when they are transferred and backed up and it involves the Data layer. In the end also another recommendation is useful: the number 10 If there are customized tools, it is important to understand that, to allow portability, they have to be redesigned and implemented again. A possible alternative is that the new cloud provider provides these tools and it involves the Data layer as the previous recommendation. Privacy The most significant recommendations for the provacy area, related to possible issues against which a company may incur are the number 5, 7 and 8. These recommendations deal in particular to the categorization of the data used by the company, security procedures adopted by the company to handle data breaches and data requirements defined by laws and regulations. Figure 5.6.: Graphical representation for privacy domain As is possible to see in the matrix in Figure 5.6, the first recommendation useful is the number 5 It is important that a procedure to handle breaches is carefully defined. and involves the Business layer. The second recommendation useful is the number 7 If there are some data that should not be seen by competitors, think twice about storing them into the cloud and it involves, instead, the Strategy layer. As the recommendation already mentioned, also the recommendation number 8 Companies should
47 5. Representations Extensions 45 check if they can store specific data into the cloud, that is if it is permitted by the law and regulations is useful and involves the Strategy layer. Security and disaster recovery Concerning the security and disaster recovery area is not shown any matrix. This because all the best practices described in Chapter 4, are related to the relation between company and cloud provider. Since the choice of the cloud vendor is made a priori, the extension, does not relate with the architectural description of the company made a priori, does not affect this area. Service availability Regarding the service availability area, all the best practices described in Chapter 4, are related to the SLA and the availability of web services and of resources by the clud vendor. This means that the choice has depended on the cloud vendors. Also this time it has already done a priori. However, it is still possible to make some important considerations. Indeed, the exemplification of a possible scenario described in Chapter 4, made us understand that service availability is really important to do not impact the mission of the company. As already stated there are threats that can influence the availability, temporarily or permanently and thus they can have negative effects on the mission of the company and its business. All these considerations lead us to the inference that the level involved is the Business layer. Thus, how is possible to see in the matrix in Figure 5.7, it is marked with the symbol of warning of yellow colour. Final Framework Extended Figure 5.8 shows a global vision of the framework. As is possible to see in that matrix, this time we can find on the abscissa axis all domains of a company that must be taken into account to understand if move into the cloud is or is not the right choise. On the ordinate axis, instead, the matrix is composed by the five layers that characterize the structure of a generic enterprise architecture framework. In this representation each matches between the elements of the ordinate axis with the elements of the abscissa axis produces different types of warning. The types of warning depend on how many recommendations or factors (in the case of the service availability) of the differents domains, involve the architectural elements that represents a company. If the recommendation to evaluate is only one the symbol of warning is yellow. If the
48 5. Representations Extensions 46 Figure 5.7.: Graphical representation for service availability domain recommendations to evaluate are two the symbol of warning is orange and if the recommendations to evaluate are three or more the symbol of warning is red. As already explaned in the paragraph above, concerning the security and disaster recovery, there are no symbols of warning that involve the that domain.
49 5. Representations Extensions 47 Figure 5.8.: Graphical representation of the complete framework
50 5. Representations Extensions Graphical representations applied to a generic framework As already said at the beginning of the Chapter, this proposal is valid for a generic EA framework composed by the levels technology, applications, data, business and strategy. Since a specific framework is not analyzed, it is not possible to state exactly what are the modeling languages used in each level. Anyway, considering the definition of each level, it is possible to identify some representations used. For each representation, it will be shown a possible way to extend it, in order to highlight the main issues related to the shift in a cloud environment. The extensions we propose, appear in each representation as icons of different colours. Each icon identifies one issue related to the cloud readiness of the company. A list describing each icon, follows. Application Credential Protected: the credentials of the application must be protected. Encryption System Conform to Standard: the encryption system used should conform to the existing standards. Storage & Usage of Data Encryption: data must be secured - that is, encrypted - during the storage and the usage. Encryption of Keys: encryption keys must be protected - that is, encrypted. Assets Audits: assets should be subjected to periodical audits. Risk Analysis: a risk analysis of the assets and applications should be performed. Encryption needed: needed. encryption of data and applications Redesign Needed: application redesign needed, to guarantee portability and interoperability. Service Availability: service availability issues. Compliance: compliance with existing privacy regulations. Deadline: presence of a deadline within a process.
51 5. Representations Extensions 49 Multiple Access: presence of multiple access of a resource. Customized: applications and data formats are customized, that is not in accordance to any standardm or adapted from a standard specification. Standardized: applications and data formats are standardized, that is, they are in accordance to a specific standard. Personally identifiable information: privacy type of a datum. Sensitive information: privacy type of a datum. Information categorized as sensitive: privacy type of a datum. Usage data: privacy type of a datum. Unique device identities: privacy type of a datum. Technology The technology level deals with the description of the infrastructure of the company. Software and hardware elements that support the application layer are represented together with their interrelations, as shown in Figures 5.9 and 5.10 (adapted from Hinkelmann (2011)). The main elements that can appear in this level are physical devices, networks or software, like operating systems, middleware or databases. This level is mainly affected by the area of governance and risk management. In particular, the company has to be compliant to laws and internal regulations. For this reason, the assets represented in this level, that need to be inspected should be marked. The different types of inspection is strictly related to the company. In general terms, there can be identified at least two different types of control. The former deals with the necessity to perform, periodically, assets audits. The latter deals with the analysis of the risk associated to specific assets, considering different scenarios. The presence of databases, anyway, could lead to the necessity to indicate that there are data that must be managed carefully because of privacy concerns. If there is a database which includes a datum that belongs to one of the category described in Chap. 4, it has to be marked with a symbol expressing the presence of privacy issues.
52 5. Representations Extensions 50 Figure 5.9.: Graphical representation of the technology level adapted from Hinkelmann (2011) Concerning the applications, in the current level, they just inherit their features described in the application level. All the symbols used to mark a specific application will be reported in this level. Applications The application level describes the applications used by the company. This includes their internal behavior and structure, as shown in Figure 5.11 and 5.12 (adapted from Hinkelmann (2011)), the interrelations between them, as well as how they are used by other applications. The main graphical extensions for this level deal with different issues. First of all, considering the area of application security and encryption, each application should be marked in order to show their level of security should be increased, in order to go into the cloud. It is also necessary to perform risk analysis determined by laws or internal regulations. Moreover, each application should be classified considering the level of standardization. Applications can use interfaces which are standardized or customized. The type of the interface used by an application is reported in the graphic of the application itself. If the interface is customized, then the application needs a rec 2012 School of Business, FHNW, Institute for Information Systems, H. Wache
53 5. Representations Extensions 51 Figure 5.10.: Graphical representation of the technology level adapted from Hinkelmann (2011) design. The necessity of a redesign is communicated by using a special icon. Please notice that a scenario in which an application needs a redesign and it uses a standardized interface, must not happen. In addition to that, it is also necessary to consider the need to encrypt the files used by the applications. This can be done, for instance, by adding a symbol in the representation of the interactions of a specific application. If an application deals with data considered as private, then the application itself should be labeled with the privacy icon (see Figure 5.11). Data The data level, intuitively, aims to represent the data used by the company. They can be represented in many ways, by using different models. Anyway, talking in general terms that is without considering a specific framework and, thus, a specific representation for the current level the data used by the company and the relations between them can be described, for instance, with a UML diagram. It can be hypothesized that another alternative would be to use a terms and fact types representation or an E/R diagram. Nevertheless, each datum used by the company has some specific values considering its sensitiveness. As already explained in Chapter 4, data can be grouped in different categories, which are personally identifiable information, sensitive information, inforc 2012 School of Business, FHNW, Institute for Information Systems, H. Wache
54 5. Representations Extensions 52 Figure 5.11.: Graphical representation of an internal behavior of an application adapted from Hinkelmann (2011) mation categorized as sensitive, usage data and unique device identities. The graphic representation used in the current level, without considering the specific language or standard chosen, will include some symbols expressing the features of a specific data. There will be as many symbols as the number of the different categories of data. In this way, it will be possible, for instance, to understand the type of a specific datum that an employee is managing. If a datum is referenced by a model of another level, all its features will be included in the representation. As an example, if a business process description has a reference to a specific datum that is classified as sensitive information, the business model will include the datum used, marked with the special symbol expressing the category it belongs to. Business As can be seen in Figure 5.8, the business level is mainly affected by the service availability problem. A possible representation which deals with this layer is the description of a business process. The representation proposed in Figure 5.14 is based on the Business Process Modeling Language. Anyway, the approach used to mark specific tasks or elements used in the process, is independent on the language used. What it is important to notice in this level, is that the company should immediately see
55 5. Representations Extensions 53 Figure 5.12.: Graphical representation of a structure of one or more applications or components adapted from Hinkelmann (2011) if a specific process is at risk of service availability. For this reason, the overall process should be marked with a symbol expressing the degree of service availability that should be guaranteed. The definition of the degree and a proposal of the symbols can be found in the knowledge representation section. As explained later on, it s important to take into account that the problem of service availability is strictly related to a specific cloud provider. This means that it is not possible to say if a process is highly risky or is safe without considering the capabilities of the cloud vendor or the service offered by it. Nevertheless, there are some features of the process, still related with service availability, that can be represented in any case. As explained in the next section, these features are related to the presence of a deadline and multiple access to a resource. Each activity which requires multiple access to a resource, will be marked with a special symbol. The same applies when an activity is managed by the presence of a deadline. The description of business processes can include also some documents or data storage used during the activities described. Even if they are represented, in a more detailed way, at different levels of the architectural description, it would be preferable to add some indications of their characteristics if necessary. This means that if a business process uses a document that is considered as sensitive in the data level, this information should be reported also in the description of the business process. It is possible to hypothesize that, once the features of a specific datum are defined at the data level, they can be automatically reported in the business process description, by simply referencing that specific datum. This is why in Figure 5.14 the document used
56 5. Representations Extensions 54 Figure 5.13.: UML graphical representation for the data level has a symbol showing that it s sensitive. Strategy As is possible to see in the matrix in Figure 5.8, the strategy level is the unique level not affected. It does not need a graphical extension. It can be hypothesized that possible representation models would be the Business Motivation Model or organization models. In this level the company expresses which goals it would like to reach and what are the actions needed to do it. Of course, the decision of the usage of an encryption algorithm or the categorization of the data used, impact this level. Nevertheless, symbols expressing possible cloud computing issues don t give any additional value in this level, since it just describes the strategy that the company would like to have. As already shown, the symbols used are quite specific and they express possible dangers related to assets, data or information used, features of the processes. This is the reason why they are used in the lower levels of the generic framework considered Knowledge representations Knowledge representations allow to express cloud computing best practices in a semantic way, in order to automatize their description and to relate them to the graphical representation. The automatization takes place by using, for instance, the business rules approach.
57 5. Representations Extensions 55 Figure 5.14.: BPMN graphical representation for the business level Formal business rules need a previous definition of terms and fact types. In Appendix A the main term and fact types used in each domain are listed. The main business rules for each area are shown in the next section. Formal rules will consider an approach similar to the Semantic of Business Vocabulary and Rules of the OMG Application security and encryption In Chapter 4 some best practices related to this area are listed. Many of them can be used to extend the architectural description of the company in order to mark important features of the company scenario, like the need of encryption for specific data. The recommendations that can be considered to extend the architectural representation deal in particular with the management of credential and encryption keys, the need of encryption for particular data and files, as well as the compliance to existing encryption standards. The main best practices related to these issues are the number 2, 5, 6, 9, 12 and 13. These guidelines deal with the architectural description of the company. This is the main reason why it has been chosen to provide a knowledge and graphical extension. The remaining best practices deal with different aspects of the company. As an example, the recommendations number 1 and 3 are really generic and are related to the concept of encryption given in number 5. Recommendations number 4, 7, 10 and 11 refer to the cloud provider. They don t deal with the enterprise architecture representation but they are guidelines to be followed after the architectural description is improved.
58 5. Representations Extensions 56 These recommendations impact different views of the company. In particular, they deal with the applications, data and scope perspectives. Applications are affected by these best practices since they should use a method of encryption in order to safely manage the information. For this reason, it s important to define this need on the application level of the company description. Data, in this case, are viewed as the files used by the applications, and they need to be encrypted during the storage and the usage. The data represented in the data level of the company description should be marked, in order to say that they should be managed with attention if shifted into a cloud environment. The scope level is affected in a more general way. The usage of a method of encryption could be seen as a strategy of the company. It s important to state that if the company goes to the cloud, it should conform to an existing standard. A formal description of terms and fact types is given in Appendix A. In general terms, the main entities involved deal with the presence of applications and related credentials, files, encryption algorithms and related encryption keys as well as the standardization of the encryption method and all the relations between these entities. A graphical descritpion of the terms and fact types involved can be found in Figure After having described the main entities involved in this domain, it s necessary to de- Figure 5.15.: Graphical representations of terms and fact types involved in the domain application security and encryption fine the business rules. Business rules describe the extensions that can be added to the architectural description, as well as how it should be done. A proposal of some SBVR operative rules for the area application security and encryption follows. They are derived by the related knowledge representation and entities
59 5. Representations Extensions 57 described in Appendix A. 1. It is obligatory that each Credential is encrypted if Application hascredential Credential. 2. It is obligatory that each File hasencryptionstorage EncryptionMethod if Application usesfile File. 3. It is obligatory that each File hasencryptionusage EncryptionMethod if Application usesfile File. 4. It is obligatory that the EncryptionMethod used for the storage of a File is different than the one used for the usage of that File. 5. It is obligatory that each EncryptionMethod has Standard is true if Application usesmethod EncryptionMethod or Credential usesencryption EncryptionMethod or EncryptionKey isencryptedby EncryptionMethod or File hasencryptionstorage EncryptionMethod or File hasencryptionusage EncryptionMethod. 6. It is obligatory that each EncryptionKey isencryptedby EncryptionMethod. These rules should be strongly considered if the company is evaluating the possibility to go into the cloud. In this case, the rules will be represented by using the operative form. This choice is determined by the fact that the encryption is needed in a cloud environment, but there could be the possibility of a violation of this approach. As an example, if the method of encryption used is not working because of a downtime, then the encryption of data won t be available. Anyway, even if the usage of encryption can be violated by many causes, it must be enforced in order to work in a safe cloud environment Governance and risk management As already described in Chapter 4, governance and risk management deal with problems and risk evaluation related to the assets of the company. The main best practices related to this issue that can be helpful in order to extend the architectural description of the company are number 1 and 6. These are recommendations dealing with activities that should be executed no matter what is the cloud provider. The remaining guidelines are not represented because they are not related to the enterprise architecture description (number 2) or they refer to something that has to be done after the shift to the cloud scenario (3 and 7). Sometimes they refer to the definition of a service level agreement and to the involvement of the company in defining it (4
60 5. Representations Extensions 58 and 5). Finally, number 8 refers to the relations among the employees working inside the company. The architectural objects affected by the chosen recommendations and related extensions, are the applications, data, processes, elements of the infrastructure (e.g. servers), as well as the company s scope. Applications, data, processes and the elements of the infrastructure can be considered as assets of the company. Each of them, can be further described by adding the related threat or vulnerability, if present. The scope of the company is affected since the company should extend its view in terms of important procedure to execute for business sake. The new procedures that should be considered deal with the security control of specific assets and the deployment of risk planning. In order to describe the main business rules related to these issues, it s necessary to define the most important terms and fact types. A formal definition can be found in Appendix A. In general terms, they include all the assets of the company, the possible threats and vulnerability, risk plans, audit as well as the relation between all these entities. A graphic description of the terms and fact types involved can be found in Figure A proposal of some SBVR operative rules for this domain follows. They are derived by the related knowledge representation described above and the terms and fact types described in Appendix A. 1. It is obligatory that Company executes SecurityControl if Company owns Asset. 2. It is obligatory that Company isawareofthreat Threat if Asset haspossiblethreat Threat. 3. It is obligatory that Company isawareofvulnerability Vulnerability if Asset haspossiblevulnerability Vulnerability. 4. It is obligatory that Company plans RiskPlan and RiskPlan includesthreat Threat if at least one Asset haspossiblethreat Threat. 5. It is obligatory that Company plans RiskPlan and RiskPlan includesvulnerability Vulnerability if at leat one Asset haspossiblevulnerability Vulnerability. 6. It is obligatory that Company performs Audit and Audit involves Datum. These business rules can be viewed as mandatory. The business and the operations of the company are governed by company s policies. Usually, a policy is something that must be strictly followed. It is very likely that once a company has decided to go into the cloud, its policies are extended to cover all the related issues of new risks. From a
61 5. Representations Extensions 59 Figure 5.16.: Graphical representations of terms and fact types involved in the domain governance and risk management different perspective, the considered company, has to extend its policies in order to go on with its business and to manage new risky scenarios. Nevertheless, these business rules will be represented in an operative form. Even if it s really important to establish new policies, there could be the possibility that one of these rules is violated. Consider, as an example, the case of security controls. These have to be executed by the company - or, in other words, by some responsible employee of the company - periodically. If the employee gets sick in the scheduled day, the security control could not take place. Even if the occurrence of this situation is really low, this is an unfavorable scenario that will violate the policy. This means that the rule must be enforced but, as shown, can be violated. Considering the possibility of rules and policies violation, it could be necessary to establish penalty measures but also a secondary plan, allowing the security control to take place Incident management As described in Chapter 4, incident management deals with all the practices to avoid or to minimize the consequences of incident events. The best practices that are considered to extend the knowledge and graphical reprec 2012 School of Business, FHNW, Institute for Information Systems, H. Wache
62 5. Representations Extensions 60 sentation of this domain are number 1 and 6. Both of them deal with the enterprise architecture description and with important features related to incidents, as well as the ways to minimize incidents consequences. The recommendation number 2 is more related with the choice of a cloud provider. Anyway, companies can determine which incident response procedures would like to have, before considering any cloud vendor. The remaining guidelines are not considered since they are related with the choice of a cloud provider (3, 5, 7), or they are not related to the enterprise architecture representation (4, 8). The architectural layers affected by these best practices are the data level and the scope level. The first one is affected since it s necessary to define which data are considered as private and which encryption algorithm is used. The scope level is affected because the company has to define the events that must be considered incidents and the incident response procedures it would like to have. A formal definition of the terms and fact types needed to define the business rules for this domain, is provided in Appendix A. A graphic description of the terms and fact types involved can be found in Figure The business rules needed in this area can be considered as operative, since it can Figure 5.17.: Graphical representations of terms and fact types involved in the domain incident management happen that someone violates them. They are derived from the terms and fact types described in Appendix A. 1. It is obligatory that Datum usesencryption EncryptionMethod if Company uses- Datum Datum and Datum isprivate private set true. 2. It is obligatory that each Event isincident incident set true or false. 3. It is obligatory that Company usesincidentprocedure IncidentResponseProcedure.
63 5. Representations Extensions Portability and interoperability As already discussed in Chapter 4, portability and interoperability issues deal with the ability of the company to change cloud provider or to have, at the same time, more than one cloud vendor. The main best practices considered, in order to extend the architectural representation of the company, are number 4, 6 and 10. They mainly deal with the applications interfaces and data formats used, as well as security measures for transferring data and for storing them. The recommendation number 6 is considered, in this case, as the necessity to use an encryption method to secure the transfer of data and application. This means that in the architecture representation, there will be added the need to use an encryption method. The choice of the best method to be used is up to the company. There are no guidelines to define the main requirements that let a method be the best one. For this reason, the company is quite free to select the method it prefers. The remaining best practices can t be considered since they are related with control measures and guidelines that should be considered, after having decided to go into the cloud. The enterprise architecture levels affected by the extensions are the data level, the application level and the scope level. The first one is affected since it s necessary to describe the format of the data used, that is if they are standardized or not. The second one, is affected because it s necessary to describe which application interfaces are used. The last one is affected because of the involvement of security measures (e.g. encryption methods) for the transfer of data. The terms and fact types needed to define the main business rules for this domain, can be found in Appendix A. A graphic description of this terms and fact types can be found in Figure The business rules of this domain are handled as operative, since they can be violated in some ways (e.g. no encryption method defined for a specific datum, due to a forgetfulness). 1. It is obligatory that each Application usesappinterface ApplicationInterface and each ApplicationInterface isapplicationstandard applicationstandardized set true or false if Company usesapplication Application. 2. It is obligatory that each Datum usesdatumformat DatumFormat and each DatumFormat isdatumstandard datumstandardized set true or false if Company usesdatum Datum. 3. It is obligatory that each Application usesmethod EncryptionMethod if Company usesapplication Application.
64 5. Representations Extensions 62 Figure 5.18.: Graphical representations of terms and fact types involved in the domain portability and interoperability 4. It is obligatory that each Datum usesencryption EncryptionMethod if Company usesdatum Datum. 5. It is obligatory that Application needsredesign RedesignNeeded is true if Application usesappinterface ApplicationInterface and each ApplicationInterface isapplicationstandard applicationstandardized is false. The issue of standard applications is very important for the area of portability and interoperability. According to Federal Office for Information Security (2011), standards allow to run the system in different cloud environments. The National Institute of Standards and Technology (n.d.) has identified a set of standards important for cloud computing. A set of them, their purpose and additional notes can be found in Table 5.1. Considering the concept of standard formats, some hypothesis can be made. Even if a company uses a certain standards to encode their documents, this doesn t guarantee that it will be possible to interoperate with another cloud provider. The main problem is related to the personalization of standard formats. In reality, it s really likely that companies adapt a standard to their needs, not being anymore able to exchange information without specific efforts to map them. For this reason, cloud customers should take into account that, before going into the cloud, it s important to test if the standards they use are compatible with the ones of the cloud vendor.
65 5. Representations Extensions 63 Name Purpose Notes XML (Extensible Markup Translating documents in a Language) machine-readable form. HTML (HyperText Markup Markup language for web Used in web pages. Language) pages. SOAP (Simple Object Access Protocol to exchange struc- Used in web sertation Protocol) tured data in the implemenvices. of web services. XML Signature Used to sign data and documents of any type. XML Encryption Syntax and Encryption and decryption of Processing OVF (Open Virtualization Format) OCCI (Open Cloud Computing Interface) CDMI (Cloud Data Management Interface) Privacy digital content. Manages and addresses the portability and interoperability of virtual machines. API for the vendor s management framework. Interface used by applications to create, delete, update and retrieve data from the cloud. Table 5.1.: Standards used in Cloud Computing Privacy issues and related guidelines have already been described in Chapter 4. The main best practices that allow to extend the architectural representation of the company are number 5, 7 and 8. These recommendations are related to the categorization of the data used by the company, the security procedures adopted by the company to handle data breaches, as well as data requirements defined by laws and regulations. All these issues can be added to the architectural representation of the company, in order to keep explicit the main problems related to privacy. The remaining best practices are related with the characteristics of the cloud provider. These are guidelines that should be considered after having decided to shift the business to the cloud. Since they include concepts usually expressed into the SLAs and not directly related to the architecture of the company, they won t be included among the extensions. The architectural levels affected by these extensions are the data level and the scope level. The former is affected since it s necessary to categorize the data used by the company. The latter, since it s necessary to identify the laws and regulations that the company must adhere to as well as to define the privacy security procedures adopted. The terms and fact types needed for defining the business rules for this domain, can
66 5. Representations Extensions 64 be found in Appendix A. A graphic description of them can be found in Figure The business rules of this area are considered as operative. This choice is made Figure 5.19.: Graphical representations of terms and fact types involved in the domain privacy considering the possibility of violations of them. As an example, even if the company must adhere some regulations, there is always the possibility that some of them are not applied. This means that they can be violated, but must be enforced. The business rules are derived from the terms and fact types defined in Appendix A. 1. It is obligatory that Company usesincidentprocedure PrivacySecurityProcedure if Company usesdatum Datum. 2. It is obligatory that each Datum generalizes exactly one PersonallyIdentifiable- Information or SensitiveInformation or InformationAsSensitive or UsageData or UniqueDeviceIdentities if Company usesdatum Datum. 3. It is obligatory that Company adheresto PrivacyLaw Security and disaster recovery For this domain, no extensions can be provided. All the best practices described in Chapter 4, are related to the relation with the cloud provider. This means that the choice of the cloud vendor has already been done and that the extensions are not related with the architectural desription of the company made a priori. Some advices for data security and disaster management are given, but they are still related to the characteristics of the cloud provider (e.g. disaster recovery plans, security standards). This means that there is no general information that can be added to the architectural representation of the company, helping the firm to evaluate its potential. In all the guidelines given, the choice of going into the cloud is already done. These are the main reasons for not giving any business rules for this domain.
67 5. Representations Extensions Service availability In Chapter 4, we briefly described a possible scenario where service availability is really important not to impact the mission of the company. In general terms, service availability is always important but it becomes very critical for companies dealing with time constraints, that is dealing with processes and procedures that should be executed in real-time. It s important to notice that problems with real-time processes can impact not only the mission or profits of the company but also the well-being of people (e.g. management of a nuclear power-plant). The system availability problem is mainly related with the provision of a service but also with the resources that allow the service to be executed. For this reason, when a company evaluates the possibility to go into the cloud, it should be able to say if its processes are risky in terms of service availability. Possible threats could be the presence of time constraints - they can also be seen as a deadline - and multiple access to the same resource done by several applications or people. In the presence of a similar scenario, if the number of resources that can be scaled up is limited and the process is classified by the company as risky, there could be a problem of service availability. To be able to evaluate if a process shifted to the cloud could be risky in terms of service availability, companies should define a way to measure its features. A possible way would be to define some business rules that, after having considered the most critical features of a process, are able to determine the existence of risks related to that process. The process features that should be considered are different and are related to the company and to the purpose of the process itself. It s also important to consider some characteristics of the service offered by the cloud provider. To give an example of business rules and of a possible approach to this problem, it will be considered the scenario of a university. The university has shifted into a cloud environment a web service and has some resources available to run the service. The purpose of the service is to gather information and data about students and their preferences in order to manage their enrollment to the courses of the next semester. The enrollment procedure has a deadline and it s possible to hypothesize that the students will send the needed data few days before the last one available. In this case, the most important features of the process that should be considered are: deadline: a specific time-limit for the enrollment procedure; number of multiple access: the number of people that will access the same service and, consequently, the same resources at the same time; number of risky task of the process: a risky task is a task, within a process, that could be executed by many users at the same time and that will access a specific resource.
68 5. Representations Extensions 66 It s important to notice that, even if we are talking about a specific scenario of a university, these features can be considered for other scenarios too. One possible way to group the features of the process in a schematic way, would be to build up a decision table. This table will consider the different characteristics of the process and their possible values. As an output, it will give some suggestions related to the degree of risk of the process. It s also possible to give different weights to the different features, in order to value more the most important. Table?? shows the decision table for a scenario in which the features number of multiple access, deadline and number of tasks are important. More precisely, the truth value related to number of multiple access should be considered as a comparison with a threshold identifying the number of multiple access guaranteed by a cloud vendor. The same applies to the truth value for number of tasks, where the value is derived from a comparison between the total number of tasks of a process and the number of tasks that will be, potentially, executed by many people at the same time. Moreover, these three features are weighted in a different way. The deadline could be considered the most important and its weight is 50%. This happens since the presence of a deadline triggers the most risk of system availability. The number of multiple access is weighted as 30%. Finally the number of tasks executed by multiple users (or applications) at the same time, is weighted as 20%. The decision table shows different outcomes: Highly risky: really high probability that the process will be used by many users or applications at the same time. There is a strong possibility that, if the capabilities of the cloud provider are not good, there could be a service unavailability. The customer company should choose a really good vendor, able to satisfy its needs in terms of resources scalability. Additionally, the SLA should be examined carefully, especially the part of vendor responsibilities, terms of the service and penalties if the service can t be provided. Risky: high probability that the process will be used by many users or applications at the same time. To avoid service unavailability, the customer company should choose the appropriate service provider and should take care about the definition of the SLA. Also in this case, the most important parts are the vendor responsibilities, terms of the service and penalties if the service can t be provided. Manager s choice: the process is considered 50% risky and 50% safe. Managers should choose the right service provider (that is, a service provider with the right capabilities) and should define a good SLA in order to have securities if the vendor is not able to provide an adequate service (as written in the contract).
69 5. Representations Extensions 67 Standard: the probability that the process will be used by many users or applications at the same time is low. The need of resource scalability is low. Safe: the probability that the process will be used by many users or applications at the same time is really low, almost zero. Usually there isn t a particular need to scale up many resources. The next step would be to represent the decision table in form of business rules. In this way, the main guidelines and related controls, could be automatized. To do that, it s necessary to define the main terms and fact types for this scenario. A formal description of them, can be found in Appendix A. In general terms, they involve processes, tasks as well as the relations between them. They also consider important features of tasks - like if it can be executed by many users at the same time - and processes - like the presence of a deadline, the total number of tasks and how many of them are considered as risky. A graphic description of the terms and fact types involved in this domain, can be found in Figure A proposal for some business rules for the area service availability follows. They Figure 5.20.: Graphical representations of terms and fact types involved in the domain service availability are derived by the related knowledge representation described above and the related terms and fact types described in Appendix A. The approach proposed uses structural business rules. The choice of structural rules is determined by the fact that these rules
70 5. Representations Extensions 68 define how the company defines its world - that is, defines the behavior related with process and risk of service unavailability. 1. It is necessary that Process hasoutcome highly risky if Process hasdeadline is true and numberriskytask is greater than numbertasks and Company evaluates Vendor and numbermultipleaccess is greater than accessguaranteed. 2. It is necessary that Process hasoutcome risky if Process hasdeadline is true and numberriskytask is not greater than numbertasks and Company evaluates Vendor and numbermultipleaccess is greater than accessguaranteed. 3. It is necessary that Process hasoutcome manager s choice if Process hasdeadline is false and numberriskytask is greater than numbertasks and Company evaluates Vendor and numbermultipleaccess is greater than accessguaranteed. 4. It is necessary that Process hasoutcome standard if Process hasdeadline is false and numberriskytask is not greater than numbertasks and Company evaluates Vendor and numbermultipleaccess is greater than accessguaranteed. 5. It is necessary that Process hasoutcome risky if Process hasdeadline is true and numberriskytask is greater than numbertasks and Company evaluates Vendor and numbermultipleaccess is not greater than accessguaranteed. 6. It is necessary that Process hasoutcome manager s choice if Process hasdeadline is true and numberriskytask is not greater than numbertasks and Company evaluates Vendor and numbermultipleaccess is not greater than accessguaranteed. 7. It is necessary that Process hasoutcome standard if Process hasdeadline is false and numberriskytask is greater than numbertasks and Company evaluates Vendor and numbermultipleaccess is not greater than accessguaranteed. 8. It is necessary that Process hasoutcome safe if Process hasdeadline is false and numberriskytask is not greater than numbertasks and Company evaluates Vendor and numbermultipleaccess is not greater than accessguaranteed. It s important to notice that to determine the extent of service unavailability, the company should have already identified some possible cloud vendors. This is an important step for the evaluation of risk, since it s necessary to know the number of multiple access guaranteed by the vendor. Anyway, in general terms, to evaluate if a service could have availability problems, it s necessary to know the characteristics of the possible solutions. For the reasons cited above, this domain is considered as an exception since it s strictly
71 5. Representations Extensions 69 related to the offer of a specific cloud provider. This means that the general features related to the processes of the company (e.g. presence of a deadline, number of tasks and risky tasks, number of multiple accesses) can still be described in the architectural description. Nevertheless, it s important to notice that it s not possible to show the degree of risk of a specific process if there is no information about a possible cloud vendor or about the number of multiple accesses guaranteed. This leads to the necessity to identify possible cloud providers in order to determine the final risk of a process. Number of multiple access Deadline Number of risky tasks Outcome Symbol V V V Higly risky V V F Risky V F V Manager s choice V F F Standard F V V Risky F V F Manager s choice F F V Standard F F F Safe Table 5.2.: Service availability decision table 5.3. SLA representation In a cloud environment scenario, Service Level Agreements are really important in order to define responsibilities, requirements, guidelines and penalties. SLAs description can be automatized and included in the architectural description of the company. There are many languages used to describe the SLAs and their related entities. Koller (2011) collected many of them, trying to describe the main features. Among the ones presented, there is the Web Service Level Agreement proposed by Keller & Ludwig (2003), which allows to describe and represent an SLA in a Web environment. The Open Grid Forum proposed the Web Services Agreement which allows to desribe an SLA related to the usage of services between a service vendor and a
Institute of Architecture of Application Systems University of Stuttgart Universittsstrae 38 D 70569 Stuttgart Diplomarbeit Nr. 3538 Risk assessment-based decision support for the migration of applications
Data Protection Act 1998 Guidance on the use of cloud computing Contents Overview... 2 Introduction... 2 What is cloud computing?... 3 Definitions... 3 Deployment models... 4 Service models... 5 Layered
Best practice in the cloud: an introduction Using ITIL to seize the opportunities of the cloud and rise to its challenges Michael Nieves AXELOS.com White Paper April 2014 Contents 1 Introduction 3 2 The
Special Publication 800-146 DRAFT Cloud Computing Synopsis and Recommendations Recommendations of the National Institute of Standards and Technology Lee Badger Tim Grance Robert Patt-Corner Jeff Voas NIST
Risk perception and risk management in cloud computing: Results from a case study of Swiss companies Nathalie Brender Haute Ecole de Gestion de Genève Campus de Battelle, Bâtiment F 7 route de Drize, 1227
Cloud Service Level Agreement Standardisation Guidelines Brussels 24/06/2014 1 Table of Contents Preamble... 4 1. Principles for the development of Service Level Agreement Standards for Cloud Computing...
WHITEPAPER CLOUD Possible Use of Cloud Technologies in Public Administration Version 1.0.0 2012 Euritas THE BEST WAY TO PREDICT THE FUTURE IS TO CREATE IT. [Willy Brandt] 2 PUBLISHER'S IMPRINT Publisher:
Convergence of Social, Mobile and Cloud: 7 Steps to Ensure Success June, 2013 Contents Executive Overview...4 Business Innovation & Transformation...5 Roadmap for Social, Mobile and Cloud Solutions...7
November 09 Benefits, risks and recommendations for information security ABOUT ENISA The European Network and Information Security Agency (ENISA) is an EU agency created to advance the functioning of the
Firewall Strategies June 2003 (Updated May 2009) 1 Table of Content Executive Summary...4 Brief survey of firewall concepts...4 What is the problem?...4 What is a firewall?...4 What skills are necessary
Enterprise Architecture Tool Selection Guide Editorial Writer: J. Schekkerman Version 6.3 2011 Preface Preface An enterprise architecture (EA) establishes the organization-wide roadmap to achieve an organization
Standards for Internal Control in New York State Government October 2007 Thomas P. DiNapoli State Comptroller A MESSAGE FROM STATE COMPTROLLER THOMAS P. DINAPOLI My Fellow Public Servants: For over twenty
Investigation of IT Auditing and Checklist Generation Approach to Assure a Secure Cloud Computing Framework Rajni Maheshwari M.Tech (Computer) College of Engineering, Bharati Vidyapeeth Deemed University
PROJECT FINAL REPORT Grant Agreement number: 212117 Project acronym: FUTUREFARM Project title: FUTUREFARM-Integration of Farm Management Information Systems to support real-time management decisions and
Making Smart IT Choices Understanding Value and Risk in Government IT Investments Sharon S. Dawes Theresa A. Pardo Stephanie Simon Anthony M. Cresswell Mark F. LaVigne David F. Andersen Peter A. Bloniarz
Microsoft Solutions Framework White Paper Published: June 2002 For more information on MSF, see: http://www.microsoft.com/msf MSF Process Model v. 3.1 Contents Abstract... 4 Overview of Frameworks... 4
Google Apps as an Alternative to Microsoft Office in a Multinational Company The GAPS Project Thesis presented in order to obtain the Bachelor s degree HES by: Luc BOURQUIN Supervisor: Thierry CEILLIER,
Business innovation and IT trends If you just follow, you will never lead Contents Executive summary 4 Background: Innovation and the CIO agenda 5 Cohesion and connection between technology trends 6 About
2008 by Bundesamt für Sicherheit in der Informationstechnik (BSI) Godesberger Allee 185-189, 53175 Bonn Contents Contents 1 Introduction 1.1 Version History 1.2 Objective 1.3 Target group 1.4 Application
CIC Guide: Continuous Delivery Realization Enterprise DevOps realities and a path towards Continuous Delivery A Creative Intellect Consulting Executive Summary Report IT as a competitive advantage is an
Exploiting the Experience of Transformation IT Outsourcing 2006 IT World Limited on behalf of the BuyIT Best Practice Network Page 1 P12 IT Outsourcing May 2006 Forewords One of the prime objectives of
An introduction to Service Integration and Management and ITIL Kevin Holland AXELOS.com White Paper January 2015 Contents Foreword 3 Introduction 4 Models for SIAM 7 Principles and considerations 9 The
ARTICLE 29 DATA PROTECTION WORKING PARTY 01037/12/EN WP 196 Opinion 05/2012 on Cloud Computing Adopted July 1 st 2012 This Working Party was set up under Article 29 of Directive 95/46/EC. It is an independent