Putting Cloud security in perspective

Transcription

1 Capgemii Immediate Istat. Flexible. Revolutioary. the way we see it Puttig Cloud security i perspective The move towards Cloud Computig will be see as oe of the defiig treds of There is growig acceptace that the Cloud delivery model offers real busiess beefits, however perceived security cocers threate the geeral uptake of the Cloud Computig model. May take the view that the Cloud Model is somehow iheretly less secure tha more traditioal IT delivery models. This paper examies how orgaisatios ca take advatage of Cloud-based services while maagig risk resposibly. First it is imperative to defie what we mea by Cloud Computig, as the term remais somewhat ebulous. Some argue that it is re-badged utility computig, some that it is more a atural evolutio of traditioal outsourcig models, ad others that it is simply a retur to the maiframe model. For the purposes of commo uderstadig i the rapidly evolvig world of Cloud Computig, we will take the widely adopted defiitio of Cloud put forward by NIST, which suggests that Cloud Computig has: Five Essetial Characteristics : O-demad self-service Broad etwork access Resource poolig (i.e. some form of multi-teacy) Rapid elasticity Measured service (use-based charges) Three Service Models : Cloud Software-as-a-Service (SaaS) Cloud Platform-as-a-Service (PaaS) Cloud Ifrastructure-as-a-Service (IaaS) Four Deploymet Models : Private Cloud Commuity Cloud Public Cloud Hybrid Cloud Risks associated with Cloud Computig There are udoubtedly risks associated with the use of Cloudbased services, just as there are risks associated with other delivery models. The most talked about risks with Cloud Computig lie i four areas: compliace; multi-teacy; lock-i; ad availability. Compliace This embraces two areas: legislative ad regulatory compliace, such as data protectio legislatio icludig the UK Data Protectio Act 1998; ad other compliace requiremets, such as those associated with the Paymet Card Idustry Data Security Stadard (PCI-DSS). Orgaisatios are also cocered about the security of their data whe hosted i foreig atios. This has called ito questio the ability of certai host govermets to access their data, which might be doe, as a example, uder the Patriot Act i the Uited States. This latter cocer is equally applicable to more stadard models, a poit illustrated by the US govermet s seizure of the Belgium-based SWIFT orgaisatio s Europea paymets data, which had bee mirrored to a US-based operatig cetre.

2 However the difficulties of complyig with data protectio legislatio i the Cloud eviromet are ofte overplayed. For example, the Safe Harbour Agreemet betwee the U.S. Departmet of Commerce ad the Europea Uio exists to eable the persoal data of EU citizes to be exported to US orgaisatios that abide by it. There are other suitable mechaisms for eablig the export of persoal data overseas, such as through the use of Bidig Corporate Rules (BCRs) or by icorporatig the model cotractual clauses issued by the Europea Commissio. These model clauses esure compliace with EU requiremets relatig to data export (Priciple 8 of the UK Data Protectio Act 1998). Although such mechaisms are available to cotrol ad eable suitably secure data export, legal advice should be sought to esure that these stadard mechaisms are sufficiet for idividual orgaisatios. It is importat to ote that compliace ca also be a problematic area with traditioal delivery models. It is the resposibility of the ed user orgaisatio to operate withi the applicable compliace eviromet irrespective of the delivery model. I short, the ultimate resposibility for compliace caot be outsourced. Multi-teacy Multi-teacy is a core compoet of may Cloud services ad ca be foud i the use of shared storage, compute or applicatio resources. I the Cloud eviromet, orgaisatios must place their cofidece i the security barriers operated by the provider. We would argue that this placig of cofidece i a third party differs very little from whe orgaisatios place their trust i third parties for service delivery, or data hostig. The primary differece betwee the Cloud eviromet ad more traditioal outsourcig is the extet to which resources are shared. Whereas i a traditioal outsourced eviromet services will typically ru o dedicated hardware, coversely i a Cloud eviromet services will typically ru o a shared physical ifrastructure. Clearly this sharig represets a level of icreased risk, however we believe it is a risk that ca be reduced, through tailored security moitorig, ad through appropriate use of cryptographic techologies withi a comprehesive security architecture. As with ay busiess decisio, the beefits of flexibility ad value eed to be weighed agaist the disbeefit of this elevated security risk. Ofte the former will outweigh the latter, although the risk maagemet fuctio of the busiess (ad ot IT) must ultimately adjudicate i each case. Lock-i Oce a orgaisatio has built a service i the Cloud, how straightforward is it for them to move to a differet supplier? At preset, ot at all straightforward, particularly for those implemetig PaaS. If you cosider a SaaS model, the the data must be exported from the provider ad trasformed ito a format compatible with the ew target eviromet. For trasport betwee SaaS providers this may be relatively straightforward as most providers support the export of data i.csv format. However the data elemets withi these exports may still require some trasformatio if they are to support a differet target data model. 2

3 Busiess Process Outsourcig the way we see it Similarly, if a orgaisatio has built or purchased a service hosted o a PaaS Cloud the the data must, agai, be exported. However the orgaisatio ow also eeds to cosider how to migrate the code itself from oe PaaS to aother (or to a o-premise alterative).this is ulikely to be a trivial udertakig. At the IaaS level, migratio is likely to be more straightforward, provided that operatig system images are ot saved i proprietary formats that preclude them ruig o similar hypervisor eviromets elsewhere. But oce agai, data must be exported from the provider, which may be time-cosumig or eve urealistic if the data geerated ad stored o the Cloud platform is sigificat. Of course, if a orgaisatio is plaig to brig a service o-premise from a Cloud based provider the it must esure that it has all of the appropriate resources available to host the service. However all the above has to be see i perspective. That perspective is give by the sigificat busiess pai of migratig services i the o-premise world. A aalogy exists here with the early days of the electricity market i the UK, whe it was very difficult to switch betwee differet electricity providers. Icreased competitio ad the emergece of commo procedures ad techologies mea that today it could scarcely be more straightforward. Similarly, i the future, a emergece of commo methodologies ad competitio i the Cloud Computig market is likely to force the process of switchig providers to become simpler. Work is uderway o may differet stadards i the Cloud space, via the Ope Group, the DMTF ad other iitiatives, which will help to promote stadardisatio ad ecourage the developmet of a flexible ad dyamic market. Orgaisatios such as Capgemii ca help to itegrate ad maage Cloud offerigs from umerous differet providers to preset a uified service to their customers. Availability Critics of Cloud provisio ask orgaisatios to cosider what would happe were they to move ad persoal productivity services to the Cloud. They might do so, for example, through a implemetatio of GoogleApps or the Microsoft Office365. Attetio is the draw to the damage that would be caused by the loss of their coectio to the Cloud or by a outage i the Cloud service itself. Agai, this eeds to be put i proper perspective. If a orgaisatio has already outsourced its back-office fuctios to a more traditioal outsourcer the they face these risks ow. Moreover, the Cloud service is likely to offer more resiliece at a much more competitive price tha most outsourcers, due to the more distributed ature of the offerig. Of the risks outlied above we cosider oly two to be sigificatly more applicable to Cloud Computig tha traditioal delivery models: those associated with multi-teacy due to the ew attack surface ot preset i sigle teat models; ad those associated with compliace particularly where compliace requiremets madate the use of physical audits or kowledge of the physical locatio of data assets. I the mai, though, orgaisatios eed to be far more clear-eyed about the risks associated with their curret delivery model. Idividual risks associated with outdated data cetres or legacy applicatios have frequetly bee accepted over the lifetime of the existig service ad o loger receive due cosideratio or re-evaluatio i a wider cotext. Similarly, thought eeds to be give to how data is maaged, secured ad trasported withi or Puttig Cloud security i perspective 3

4 betwee orgaisatios; for example how much sesitive data is still beig trasported o uecrypted devices such as memory sticks? O the other side of the coi, Cloud Computig ca offer sigificat security beefits to a orgaisatio. These iclude, iter alia, improved data cetre security, icreased resiliece, reduced reliace o portable media, ad greater cocetratio ad retetio of skilled security resource. Here, as elsewhere, those beefits eed to be weighed i the balace. Securig Cloud Computig First thigs first: o matter what the delivery model, security is still security ad the same priciples apply. Although implemeted security techologies ad processes vary, the essetial techiques of risk maagemet, by which we mea threat modellig, risk assessmet ad assurace o risk mitigatio measures, apply equally for a Cloud service model. May blue chip orgaisatios have established security architectures, ofte tied ito a wider eterprise architecture. Where possible, Cloud security should be maaged withi such existig frameworks, i a way that takes advatage of existig impact assessmets ad assurace requiremet defiitios. A proper level of itegratio will allow a orgaisatio to protect assets i a cosistet maer across all delivery models. Moreover, it removes the ufortuate tedecy to apply stricter cotrols i the Cloud wholesale simply because of the model rather tha ay uderlyig icrease i risk or threat. May orgaisatios have established security architectures, but may more do ot. What assistace is there for these orgaisatios? O the positive side, security guidace is ofte available from the providers themselves ad from idepedet forums like the Cloud Security Alliace ad the Jericho Forum. Both of these have bee workig o the implicatios of security i Cloud-like eviromets for some time. Furthermore, orgaisatios like Capgemii have experieced staff who ca advise o the implemetatio of secure Cloud services, ad ideed cotribute to these Cloud Security fora. Ay orgaisatio cosiderig movig to a Cloud-based service must coduct a thorough, hoest ad pragmatic risk assessmet. This must be based o the threats appropriate to the delivery model ad the busiess impacts of vulerabilities beig exploited. Of course, such a risk assessmet should take place for all ew services, ot merely those destied for the Cloud. Such risk assessmets eed to be owed by the busiess. It is the role of the risk maagemet professioal to idetify ad assess risk, it is for the busiess to decide whether that risk is acceptable. Ofte, the busiess may decide to accept a security risk i exchage for icreased busiess fuctioality a perfectly ratioal decisio provided it is based o a full uderstadig of the relevat iformatio. Failure to ivolve the busiess i the process of risk assessmet may lead to the icreasigly commo problem of shadow IT. This is the term for busiess uits bypassig existig IT operatios ad adoptig Cloud services directly. For oly two thigs are typically ecessary for Cloud Service adoptio: a Iteret coectio ad a credit card. If the IT or security departmets are see as ihibitors, busiess uits ca easily bypass those perceived to be blockig progress. If a risk assessmet has bee coducted ad risks are deemed acceptable to the busiess, subject to the implemetatio of appropriate techical cotrols ad processes (Capgemii utilises a security cotrols checklist based o the Cloud Security Alliace guidace), the certai actios eed to follow: 4

5 Busiess Process Outsourcig the way we see it 1.Cosider ay requiremets sourced from existig security architectures where available. These requiremets may dictate (for example) ecryptio requiremets, evaluatio levels for firewall techologies ad service level requiremets for processes such as user maagemet or icidet respose. 2.Take these requiremets, or those sourced from a more specific exercise, ad traslate them ito a form appropriate for the proposed Cloud service ad deploymet model, esurig that accoutabilities betwee the cosumer ad Cloud provider are clearly uderstood. Typically a ed-user orgaisatio will retai most security resposibility i a IaaS implemetatio where they are resposible for security from the operatig system upwards. Coversely, i a SaaS eviromet the provider must shoulder most of the security burde as a cosumer typically oly has access to the applicatio with o visibility of the uderlyig platform or ifrastructure. The PaaS eviromet is the most complex to uderstad (for example, a customer coded applicatio makig use of Provider coded APIs) ad so cocomitatly the split of security resposibilities ca also be complex. 3.Idetify a Cloud provider most able to meet the idetified profile for provider resposibilities. Providers may make may claims regardig the security of their services, ad establishig credibility is key. Optios iclude idepedet assurace (may Cloud providers are idepedetly certified to stadards such as ISO/IEC or have bee subject to SAS70 Type 2 audits), or coductig your ow security testig of the service (usually cotrolled uder stadard provider agreemets dictatig the scope of such exercises). For Capgemii's Cloud Service Solutios we have bee able to obtai improved terms ad coditios from our Cloud provider parters. These iclude improved rights of audit ad provide evidece of the additioal value ad ifluece offered by service itegrators. Available measures Orgaisatios must also cosider how to fulfil their resposibilities while esurig that providers operate as advertised. Fortuately, the wider IT market has log recogised the eed to implemet services securely i the Cloud. May Cloud vedors ow offer optioal services to improve the security of their stadard offers. A good example beig Amazo Web Services, who offer of a Virtual Private Cloud service. This attempts to mitigate some of the risks of multi-teacy by offerig security separatio through cryptographic meas. Should a orgaisatio wish to implemet further separatio betwee their data/service ad the Cloud provider usig software produced idepedetly of the Cloud provider, the similar fuctioality is also available from CohesiveFT via their VPNCubed product. Amazo also offers host-based firewalls that are used to cotrol commuicatios with customer cotaiers. Similarly Salesforce.com allows customers to cotrol which IP addresses have access to their service. Crucially, though, orgaisatios are ot limited to the cotrols provided by Cloud vedors. The growig popularity of federated idetity maagemet allows orgaisatios to maage the access rights of their users i the Cloud from withi their ow orgaisatioal boudary. The use of stadardsbased idetity maagemet ad federatio techologies also promotes trasparecy ad iteroperability betwee differet Cloud providers ad o-premise systems. Techologies such as those from PigIdetity help to make access to Cloud-based services seamless, as well as secure, eablig a more user-friedly experiece for both ed-users ad user Puttig Cloud security i perspective 5

6 admiistrators. For those orgaisatios that require two factor autheticatio, CRYPTOCard offer a maaged autheticatio service that eables secure toke-based autheticatio to be implemeted quickly, securely ad cost-effectively. It is importat to ote, here, that i almost all eviromets people, ad their access to systems ad data, represet the weakest spot i a security solutio. This is particularly true i Cloud eviromets where access typically comes via the Web browser. Here social egieerig attacks ca be extremely serious, usig techiques such as phishig or brute force guessig to obtai user passwords, or more direct uauthorised access via cross-site scriptig. As a example, corporate iformatio relatig to Twitter was recetly exposed after a attacker compromised a accout belogig to a Twitter employee. This accout also provided access to the employee s Google Docs ad Google Apps from where the cofidetial iformatio was obtaied. The use of a strog two-factor autheticatio mechaism would have frustrated this attack. Security moitorig must also be cosidered, ad becomes eve more vital whe services ad data are hosted outside orgaisatioal boudaries or distributed across multiple Cloud providers. There it becomes a critical cotrol to maitai visibility of service levels ad security. May techical cotrols are available to implemet such protective moitorig, some Cloud-specific (e.g. CatBird), some more geeric ad some of a cotractual ad procedural ature. The most appropriate tools will deped upo the service ad deploymet models i questio. While this paper does ot attempt to provide a exhaustive assessmet 6

7 busiess Process Outsourcig the way we see it of the security mechaisms for every Cloud Computig service ad sceario, it does show that solutios are available to mitigate the most commo security risks i a pragmatic ad sesible maer. Coclusio Assessig the security of the Cloud Service model caot sesibly be doe i isolatio. Istead it must be cosidered i its proper cotext amely i compariso with the iheret risks i more traditioal models. Adoptio of Cloud Computig is ot a risk-free exercise, but or is adoptio of a more traditioal model. While the Cloud has uique challeges, those challeges do ot mea it is iheretly isecure. Ideed, alterative IT delivery models have uique challeges of their ow. Moreover their challeges, such as maiteace of agig data cetres, retetio of qualified staff, ad lack of IT flexibility or wasteful use of resources, might easily be see as more sigificat. Therefore, as a rule, security cocers should ot be a block to the adoptio of Cloud Computig. There may be data or services that are ot appropriate to place o a multi-teat Cloud service, which is perfectly uderstadable due to specific compliace requiremets or its extremely high value to the busiess. Orgaisatios eed to be sesible, busiess-focused ad pragmatic about Cloud-sourcig. Decisios should be arrived at through a uderstadig of busiess risk that looks hoestly at the associated risk withi more traditioal delivery models. Frak appraisal, ot istictive fear, should iform those decisios. Puttig Cloud security i perspective 7

8 About Capgemii Capgemii, oe of the world's foremost providers of cosultig, techology ad outsourcig services, eables its cliets to trasform ad perform through techologies. Capgemii provides its cliets with isights ad capabilities that boost their freedom to achieve superior results through a uique way of workig, the Collaborative Busiess Experiece TM. The Group relies o its global delivery model called Rightshore, which aims to get the right balace of the best talet from multiple locatios, workig as oe team to create ad deliver the optimum solutio for cliets. Preset i 40 coutries, Capgemii reported 2010 global reveues of EUR 8.7 billio ad employs aroud 110,000 people worldwide. More iformatio is available at Rightshore is a trademark belogig to Capgemii Lee Newcombe Ph.D. Security Cosultat lee.ewcombe@capgemii.com Capgemii 11, Rue de Tilsitt Paris Frace Phoe +33 (0) Fax +33 (0) Copyright 2010 Capgemii. All rights reserved.