SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

Transcription

1 SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

2 INTRODUCTION The guidance prvided herein is the third versin f the Clud Security Alliance dcument, Security Guidance fr Critical Areas f Fcus in Clud Cmputing, which was riginally released in April The permanent archive lcatins fr these dcuments are: (this dcument) (versin 2 guidance) (versin 1 guidance) In a departure frm the secnd versin f ur guidance, each dmain was assigned its wn editr and peer reviewed by industry experts. The structure and numbering f the dmains align with industry standards and best practices. We encurage the adptin f this guidance as a gd perating practice in strategic management f clud services. These white papers and their release schedule are lcated at: In anther change frm the secnd versin, there are sme updated dmain names. We have these changes: Dmain 3: Legal Issues: Cntracts and Electrnic Discvery and Dmain 5: Infrmatin Management and Data Security. We nw have added anther dmain, which is Dmain 14: Security as a Service Clud Security Alliance. All rights reserved. Yu may dwnlad, stre, display n yur cmputer, view, print, and link t the Clud Security Alliance Guidance at subject t the fllwing: (a) the Guidance may be used slely fr yur persnal, infrmatinal, nn-cmmercial use; (b) the Guidance may nt be mdified r altered in any way; (c) the Guidance may nt be redistributed; and (d) the trademark, cpyright r ther ntices may nt be remved. Yu may qute prtins f the Guidance as permitted by the Fair Use prvisins f the United States Cpyright Act, prvided that yu attribute the prtins t the Clud Security Alliance Guidance Versin 3.0 (2011) CLOUD SECURITY ALLIANCE 1

3 TABLE OF CONTENTS Intrductin... 1 Frewrd... 3 Acknwledgments... 4 Letter frm the Editrs... 6 An Editrial Nte n Risk... 8 Sectin I. Clud Architecture Dmain 1: Clud Cmputing Architectural Framewrk Sectin II. Gverning in the Clud Dmain 2: Gvernance and Enterprise Risk Management Dmain 3: Legal Issues: Cntracts and Electrnic Discvery Dmain 4: Cmpliance and Audit Management Dmain 5: Infrmatin Management and Data Security Dmain 6: Interperability and Prtability Sectin III. Operating in the Clud Dmain 7: Traditinal Security, Business Cntinuity, and Disaster Recvery Dmain 8: Data Center Operatins Dmain 9: Incident Respnse Dmain 10: Applicatin Security Dmain 11: Encryptin and Key Management Dmain 12: Identity, Entitlement, and Access Management Dmain 13: Virtualizatin Dmain 14: Security as a Service CLOUD SECURITY ALLIANCE 2

4 FOREWORD Welcme t the third versin f the Clud Security Alliance s Security Guidance fr Critical Areas f Fcus in Clud Cmputing. As clud cmputing begins t mature, managing the pprtunities and security challenges becmes crucial t business develpment. We humbly hpe t prvide yu with bth guidance and inspiratin t supprt yur business needs while managing new risks. The Clud Security Alliance has delivered actinable, best practices based n previus versins f this guidance. As we cntinue t deliver tls t enable businesses t transitin t clud services while mitigating risk, this guidance will act as the cmpass fr ur future directin. In v3.0, yu will find a cllectin f facts and pinins gathered frm ver seventy industry experts wrldwide. We have cmpiled this infrmatin frm a range f activities, including internatinal chapters, partnerships, new research, and cnference events geared twards furthering ur missin. Yu can fllw ur activities at The path t secure clud cmputing is surely a lng ne, requiring the participatin f a brad set f stakehlders n a glbal basis. Hwever, we shuld happily recgnize the prgress we are seeing: new clud security slutins are regularly appearing, enterprises are using ur guidance t engage with clud prviders, and a healthy public dialgue ver cmpliance and trust issues has erupted arund the wrld. The mst imprtant victry we have achieved is that security prfessinals are vigrusly engaged in securing the future, rather than simply prtecting the present. Please stay engaged n this tpic and cntinue t wrk with us t cmplete this imprtant missin. Best Regards, Jerry Archer Dave Cullinane Nils Puhlmann Alan Behme Paul Kurtz Jim Reavis The Clud Security Alliance Bard f Directrs 2011 CLOUD SECURITY ALLIANCE 3

5 ACKNOWLEDGMENTS Dmain Authrs/Cntributrs Dmain 1: Chris Hff, Paul Simmnds Dmain 2: Marlin Phlman, Becky Swain, Laura Psey, Bhavesh Bhagat Dmain 3: Francise Gilbert, Pamela Jnes Harbur, David Kessler, Sue Rss, Thmas Trappler Dmain 4: Marlin Phlman, Said Tabet Dmain 5: Rich Mgull, Jesus Luna Dmain 6: Aradhna Chetal, Balaji Ramamrthy, Jim Petersn, Je Wallace, Michele Drgn, Tushar Bhavsar Dmain 7: Randlph Barr, Ram Kumar, Michael Machad, Marlin Phlman Dmain 8: Liam Lynch Dmain 9: Michael Panic, Bernd Grbauer, Carl Espiritu, Kathleen Mriarty, Lee Newcmbe, Dminik Birk, Jeff Reed Dmain 10: Aradhna Chetal, Balaji Ramamrthy, Jhn Kinsella, Jsey V. Gerge, Sundararajan N., Devesh Bhatt, Tushar Bhavsar Dmain 11: Liam Lynch Dmain 12: Paul Simmnds, Andrew Yemans, Ian Dbsn, Jhn Arnld, Adrian Secmbe, Peter Jhnsn, Shane Tully, Balaji Ramamrthy, Subra Kumaraswamy, Rajiv Mishra, Ulrich Lang, Jens Laundrup, Yvnne Wilsn Dmain 13: Dave Asprey, Richard Zha, Kanchanna Ramasamy Balraj, Abhik Chaudhuri, Melvin M. Rdriguez Dmain 14: Jens Laundrup, Marlin Phlman, Kevin Fielder Peer Reviewers Valmiki Mukherjee, Bernd Jaeger, Ulrich Lang, Hassan Takabi, Pw Carey, Xavier Guerin, Try D. Casey, James Beadel, Antn Chuvakin, Tushar Jain, M S Prasad, Damir Savanvic, Eiji Sasahara, Chad Wlf, Stefan Petterssn, M S Prasad, Nrupak Shah, Kimberley Laris, Henry St. Andre, Jim Petersn, Ariel Litvin, Tatsuya Kamimura, Gerge Fergusn, Andrew Hay, Danielit Vizcayn, K.S. Abhiraj, Liam Lynch, Michael Marks, JP Mrgenthal, Aml Gdble, Damu Kuttikrishnan, Rajiv Mishra, Dennis F. Pindexter, Neil Fryer, Andrea Bilbrk, Balaji Ramamrthy, Damir Savanvic Editrial Team Archie Reed: Dmains 3, 8, CLOUD SECURITY ALLIANCE 4

6 Chris Rezek: Dmains 2, 4, 5, 7, 13, 14 Paul Simmnds: Dmains 1, 6, 10, 11, 12 CSA Staff Technical Writer/Editr: Amy L. Van Antwerp Graphic Designer: Kendall Scbria Research Directr: J.R. Sants 2011 CLOUD SECURITY ALLIANCE 5

7 LETTER FROM THE EDITORS Over the past three years, the Clud Security Alliance has attracted arund 120 crprate members and has a brad remit t address all aspects f clud security, including cmpliance, glbal security-related legislatin and regulatin, identity management, and the challenge f mnitring and auditing security acrss a clud-based IT supply chain. CSA is becming the fcal pint fr security standards glbally, aligning multiple, disparate gvernment plicies n clud security and putting frward standards fr ratificatin by internatinal standards bdies. CSA sees itself as a clud security standards incubatr, s its research prjects use rapid develpment techniques t prduce fast results. T this end, the CSA Guidance editrial team is prud t present the third versin f its flagship Security Guidance fr Critical Areas f Fcus in Clud Cmputing. This wrk is a set f best security practices CSA has put tgether fr 14 dmains invlved in gverning r perating the clud (Clud Architecture, Gvernance and Enterprise Risk Management, Legal: Cntracts and Electrnic Discvery, Cmpliance and Audit, Infrmatin Management and Data Security, Prtability and Interperability, Traditinal Security, Business Cntinuity and Disaster Recvery, Data Center Operatins, Incident Respnse, Ntificatin and Remediatin, Applicatin Security, Encryptin and Key Management, Identity and Access Management, Virtualizatin, and Security as a Service). CSA guidance in its third editin seeks t establish a stable, secure baseline fr clud peratins. This effrt prvides a practical, actinable rad map t managers wanting t adpt the clud paradigm safely and securely. Dmains have been rewritten t emphasize security, stability, and privacy, ensuring crprate privacy in a multi-tenant envirnment. Over the past tw years, versin 2.1 f the guidance has served as the fundatin fr research in multiple areas f clud security. Deliverables nw in use frm the TCI Architecture t the GRC Stack were inspired by previus versins f the guidance, and it is ur hpe that this versin will be n different. The guidance serves as a high level primer fr chief executives, cnsumers, and implementers wishing t adpt clud services as an alternative r supplement t traditinal infrastructure. Hwever, the guidance is designed with innvatin in mind. Thse with an entrepreneurial mindset shuld read this wrk with an eye tward the inferred services and appraches many f the authrs have included in the dmain creatin. Investrs and crprate decisin makers will als find this wrk f interest, as it serves as a radmap fr innvatin and develpment already in place in cmpanies thrughut the wrld. Security practitiners and educatrs will find elements f this bk bth authritative and thught prvking, and as the industry evlves, the value the authrs have included shuld prve influential and timely. In the third editin, the guidance assumes a structural maturity in parallel with multinatinal clud standards develpment in bth structure and cntent. Versin 3.0 extends the cntent included in previus versins with practical recmmendatins and requirements that can be measured and audited. Please nte that different interpretatins f the term "requirements" exist, which we use thrughut the dcument. Our guidance des nt represent a statutry bligatin, but "requirements" was chsen t represent guidance apprpriate fr virtually all use cases we culd envisin, and als aligns ur guidance with similar well-accepted dcuments. CSA industry expert authrs have endeavred t present a wrking prduct that is measured and balanced between the interests f clud prviders and tenants. Cntrls fcus n the preservatin f tenant data wnership integrity while embracing the cncept f a shared physical infrastructure. Guidance Versin 3.0 incrprates the highly dynamic nature f clud cmputing, industry learning curve, and new develpments within ther research prjects such as Clud Cntrls Matrix, Cnsensus Assessments Initiative, Trusted Clud Initiative, and GRC Stack Initiative and ties in the varius CSA activities int ne cmprehensive C-level best practice. The Security Guidance v3.0 will serve as the gateway t emerging standards being 2011 CLOUD SECURITY ALLIANCE 6

8 develped in the wrld s standards rganizatin and is designed t serve as an executive-level primer t any rganizatin seeking a secure, stable transitin t hsting their business peratins in the clud. On behalf f the Clud Security Alliance, we wuld like t thank each and every vlunteer fr their time and effrt in the develpment and editing f this new release f ur flagship guidance dcument. While we believe this is ur best, mst widely reviewed wrk t date, the tpic is still evlving and althugh ur fremst intent is t guide, we als intend t inspire the readers t becme invlved in imprving and cmmenting n the directin thse cmpsing the bdy f wrk have utlined. We humbly and respectfully submit this effrt t the industry and await the mst imprtant cmpnent f any dialg, yur pinin. We are eager t hear yur feedback regarding this updated guidance. If yu fund this guidance helpful r wuld like t see it imprved, please cnsider jining the Clud Security Alliance as a member r cntributr. Best Regards, Paul Simmnds Chris Rezek Archie Reed Security Guidance v3.0 Editrs 2011 CLOUD SECURITY ALLIANCE 7

9 AN EDITORIAL NOTE ON RISK Thrughut this Guidance we make extensive recmmendatins n reducing yur risk when adpting clud cmputing, but nt all the recmmendatins are necessary r even realistic fr all clud deplyments. As we cmpiled infrmatin frm the different wrking grups during the editrial prcess, we quickly realized there simply wasn t enugh space t prvide fully nuanced recmmendatins fr all pssible risk scenaris. Just as a critical applicatin might be t imprtant t mve t a public clud prvider, there might be little r n reasn t apply extensive security cntrls t lw-value data migrating t clud-based strage. With s many different clud deplyment ptins including the SPI service mdels (SPI refers t Sftware as a Service, Platfrm as a Service, r Infrastructure as a Service, explained in depth in Dmain 1); public vs. private deplyments, internal vs. external hsting, and varius hybrid permutatins n list f security cntrls can cver all circumstances. As with any security area, rganizatins shuld adpt a risk-based apprach t mving t the clud and selecting security ptins. The fllwing is a simple framewrk t help evaluate initial clud risks and infrm security decisins. This prcess is nt a full risk assessment framewrk, nr a methdlgy fr determining all yur security requirements. It s a quick methd fr evaluating yur tlerance fr mving an asset t varius clud cmputing mdels. Identify the Asset fr the Clud Deplyment At the simplest, assets supprted by the clud fall int tw general categries: 1. Data 2. Applicatins/Functins/Prcesses We are either mving infrmatin int the clud, r transactins/prcessing (frm partial functins all the way up t full applicatins). With clud cmputing ur data and applicatins dn t need t reside in the same lcatin, and we can chse t shift nly parts f functins t the clud. Fr example, we can hst ur applicatin and data in ur wn data center, while still utsurcing a prtin f its functinality t the clud thrugh a Platfrm as a Service. The first step in evaluating risk fr the clud is t determine exactly what data r functin is being cnsidered fr the clud. This shuld include ptential uses f the asset nce it mves t the clud t accunt fr scpe creep. Data and transactin vlumes are ften higher than expected. Evaluate the Asset The next step is t determine hw imprtant the data r functin is t the rganizatin. Yu dn t need t perfrm a detailed valuatin exercise unless yur rganizatin has a prcess fr that, but yu d need at least a rugh assessment f hw sensitive an asset is, and hw imprtant an applicatin/functin/prcess is CLOUD SECURITY ALLIANCE 8

10 Fr each asset, ask the fllwing questins: 1. Hw wuld we be harmed if the asset became widely public and widely distributed? 2. Hw wuld we be harmed if an emplyee f ur clud prvider accessed the asset? 3. Hw wuld we be harmed if the prcess r functin were manipulated by an utsider? 4. Hw wuld we be harmed if the prcess r functin failed t prvide expected results? 5. Hw wuld we be harmed if the infrmatin/data were unexpectedly changed? 6. Hw wuld we be harmed if the asset were unavailable fr a perid f time? Essentially we are assessing cnfidentiality, integrity, and availability requirements fr the asset; and hw the risk changes if all r part f the asset is handled in the clud. It s very similar t assessing a ptential utsurcing prject, except that with clud cmputing we have a wider array f deplyment ptins, including internal mdels. Map the Asset t Ptential Clud Deplyment Mdels Nw we shuld have an understanding f the asset s imprtance. Our next step is t determine which deplyment mdels we are cmfrtable with. Befre we start lking at ptential prviders, we shuld knw if we can accept the risks implicit t the varius deplyment mdels: private, public, cmmunity, r hybrid; and hsting scenaris: internal, external, r cmbined. Fr the asset, determine if yu are willing t accept the fllwing ptins: 1. Public. 2. Private, internal/n-premises. 3. Private, external (including dedicated r shared infrastructure). 4. Cmmunity; taking int accunt the hsting lcatin, ptential service prvider, and identificatin f ther cmmunity members. 5. Hybrid. T effectively evaluate a ptential hybrid deplyment, yu must have in mind at least a rugh architecture f where cmpnents, functins, and data will reside. At this stage yu shuld have a gd idea f yur cmfrt level fr transitining t the clud, and which deplyment mdels and lcatins fit yur security and risk requirements. Evaluate Ptential Clud Service Mdels and Prviders In this step fcus n the degree f cntrl yu ll have at each SPI tier t implement any required risk management. If yu are evaluating a specific ffering, at this pint yu might switch t a fuller risk assessment CLOUD SECURITY ALLIANCE 9

11 Yur fcus will be n the degree f cntrl yu have t implement risk mitigatins in the different SPI tiers. If yu already have specific requirements (e.g., fr handling f regulated data) yu can include them in the evaluatin. Map Out the Ptential Data Flw If yu are evaluating a specific deplyment ptin, map ut the data flw between yur rganizatin, the clud service, and any custmers/ther ndes. While mst f these steps have been high-level, befre making a final decisin it s abslutely essential t understand whether, and hw, data can mve in and ut f the clud. If yu have yet t decide n a particular ffering, yu ll want t sketch ut the rugh data flw fr any ptins n yur acceptable list. This is t insure that as yu make final decisins, yu ll be able t identify risk expsure pints. Cnclusins Yu shuld nw understand the imprtance f what yu are cnsidering mving t the clud, yur risk tlerance (at least at a high level), and which cmbinatins f deplyment and service mdels are acceptable. Yu shuld als have a gd idea f ptential expsure pints fr sensitive infrmatin and peratins. These tgether shuld give yu sufficient cntext t evaluate any ther security cntrls in this Guidance. Fr lw-value assets yu dn t need the same level f security cntrls and can skip many f the recmmendatins such as n-site inspectins, discverability, and cmplex encryptin schemes. A high-value regulated asset might entail audit and data retentin requirements. Fr anther high-value asset nt subject t regulatry restrictins, yu might fcus mre n technical security cntrls. Due t ur limited space, as well as the depth and breadth f material t cver, this dcument cntains extensive lists f security recmmendatins. Nt all clud deplyments need every pssible security and risk cntrl. Spending a little time up frnt evaluating yur risk tlerance and ptential expsures will prvide the cntext yu need t pick and chse the best ptins fr yur rganizatin and deplyment CLOUD SECURITY ALLIANCE 10

12 SECTION I // CLOUD ARCHITECTURE 2011 CLOUD SECURITY ALLIANCE 11

13 DOMAIN 1 // CLOUD COMPUTING ARCHITECTURAL FRAMEWORK SECURITY GUIDANCE FOR CRITICAL AREAS OF This dmain, the Clud Cmputing Architectural Framewrk, prvides a cnceptual framewrk fr the rest f the Clud Security Alliance s guidance. The cntents f this dmain fcus n a descriptin f clud cmputing that is specifically tailred t the unique perspective f IT netwrk and security prfessinals. The final sectin f this dmain prvides a brief intrductin t each f the ther dmains. Understanding the architectural framewrk described in this dmain is an imprtant first step in understanding the remainder f the Clud Security Alliance guidance. The framewrk defines many f the cncepts and terms used thrughut the ther dmains. Overview. The fllwing three sectins define this architectural perspective in terms f: The terminlgy used thrughut the guidance, t prvide a cnsistent lexicn The architectural requirements and challenges fr securing clud applicatins and services A reference mdel that describes a taxnmy f clud services and architectures 1.1 What Is Clud Cmputing? Clud cmputing is a mdel fr enabling ubiquitus, cnvenient, n-demand netwrk access t a shared pl f cnfigurable cmputing resurces (e.g., netwrks, servers, strage, applicatins, and services). Clud cmputing is a disruptive technlgy that has the ptential t enhance cllabratin, agility, scaling, and availability, and prvides the pprtunities fr cst reductin thrugh ptimized and efficient cmputing. The clud mdel envisages a wrld where cmpnents can be rapidly rchestrated, prvisined, implemented and decmmissined, and scaled up r dwn t prvide an n-demand utility-like mdel f allcatin and cnsumptin. Frm an architectural perspective, there is much cnfusin surrunding hw clud is bth similar t and different frm existing mdels f cmputing and hw these similarities and differences impact the rganizatinal, peratinal, and technlgical appraches t netwrk and infrmatin security practices. There is a thin line between cnventinal cmputing and clud cmputing. Hwever, clud cmputing will impact the rganizatinal, peratinal, and technlgical appraches t data security, netwrk security, and infrmatin security gd practice. There are many definitins tday that attempt t address clud frm the perspective f academicians, architects, engineers, develpers, managers, and cnsumers. This dcument fcuses n a definitin that is specifically tailred t the unique perspectives f IT netwrk and security prfessinals CLOUD SECURITY ALLIANCE 12

14 1.2 What Cmprises Clud Cmputing? This versin f the Clud Security Alliance s Guidance features definitins that are based n published wrk f the scientists at the U.S. Natinal Institute f Standards and Technlgy (NIST) 1 and their effrts arund defining clud cmputing. NIST s publicatin is generally well accepted, and the Guidance aligns with the NIST Wrking Definitin f Clud Cmputing (NIST as f this writing) t bring cherence and cnsensus arund a cmmn language t fcus n use cases rather than semantic nuances. It is imprtant t nte that this guide is intended t be bradly usable and applicable t rganizatins glbally. While NIST is a U.S. gvernment rganizatin, the selectin f this reference mdel shuld nt be interpreted t suggest the exclusin f ther pints f view r gegraphies. NIST defines clud cmputing by describing five essential characteristics, three clud service mdels, and fur clud deplyment mdels. They are summarized in visual frm in Figure 1 and explained in detail belw. Figure 1 NIST Visual Mdel f Clud Cmputing Definitin 2 1 NIST - Natinal Institute f Standards and Technlgy 2011 CLOUD SECURITY ALLIANCE 13

15 1.3 The Characteristics f Clud Cmputing It is imprtant t recgnize that clud services are ften but nt always utilized in cnjunctin with, and enabled by, virtualizatin technlgies. There is n requirement, hwever, that ties the abstractin f resurces t virtualizatin technlgies, and in many fferings virtualizatin by hypervisr r perating system cntainer is nt utilized. Further, it shuld be nted that multi-tenancy is nt called ut as an essential clud characteristic by NIST but is ften discussed as such. Althugh nt an essential characteristic f clud cmputing in the NIST mdel, CSA has identified multi-tenancy as an imprtant element f clud. 1.4 Multi-Tenancy Fr this dcument multi tenancy is cnsidered an imprtant element, and the fllwing sectin will utline the CSA s understanding/definitin as an imprtant element f clud cmputing. Multi-tenancy in its simplest frm implies use f same resurces r applicatin by multiple cnsumers that may belng t same rganizatin r different rganizatin. The impact f multi-tenancy is visibility f residual data r trace f peratins by ther user r tenant. Figure 2 Multi-Tenancy Multi-tenancy in clud service mdels implies a need fr plicy-driven enfrcement, segmentatin, islatin, gvernance, service levels, and chargeback/billing mdels fr different cnsumer cnstituencies. Cnsumers may chse t utilize a public clud prviders service ffering n an individual user basis r, in the instance 2011 CLOUD SECURITY ALLIANCE 14

16 f private clud hsting, an rganizatin may segment users as different business units sharing a cmmn infrastructure. Frm a prvider s perspective, multi-tenancy suggests an architectural and design apprach t enable ecnmies f scale, availability, management, segmentatin, islatin, and peratinal efficiency. These services leverage shared infrastructure, data, metadata, services, and applicatins acrss many different cnsumers. Multi-tenancy can als take n different definitins depending upn the clud service mdel f the prvider; inasmuch as it may entail enabling the capabilities described abve at the infrastructure, database, r applicatin levels. An example wuld be the difference between an Infrastructure-as-a-Service (IaaS) 2, Sftware-as-a-Service (SaaS) 3, and (PaaS) 4 multi-tenant implementatin. Clud deplyment mdels place different imprtance n multi-tenancy. Hwever, even in the case f a private clud, a single rganizatin may have a multitude f third party cnsultants and cntractrs, as well as a desire fr a high degree f lgical separatin between business units. Thus, multi-tenancy cncerns shuld always be cnsidered. 1.5 Clud Reference Mdel Understanding the relatinships and dependencies between clud cmputing mdels is critical t understanding clud cmputing security risks. IaaS is the fundatin f all clud services, with PaaS building upn IaaS, and SaaS in turn building upn PaaS as described in the Clud Reference Mdel diagram. In this way, just as capabilities are inherited, s are infrmatin security issues and risk. It is imprtant t nte that cmmercial clud prviders may nt neatly fit int the layered service mdels. Nevertheless, the reference mdel is imprtant fr relating real-wrld services t an architectural framewrk and understanding that the resurces and services require security analysis. IaaS includes the entire infrastructure resurce stack frm the facilities t the hardware platfrms that reside in them. It incrprates the capability t abstract resurces (r nt), as well as deliver physical and lgical cnnectivity t thse resurces. Ultimately, IaaS prvides a set f API s 5, which allws management and ther frms f interactin with the infrastructure by cnsumers. 2 IaaS - Infrastructure as a Service 3 SaaS - Sftware as a Service 4 PaaS - Platfrm as a Service 5 API - Applicatin Prgramming Interface Infrastructure as a Service (IaaS), delivers cmputer infrastructure (typically a platfrm virtualizatin envirnment) as a service, alng with raw strage and netwrking. Rather than purchasing servers, sftware, data-center space, r netwrk equipment, clients instead buy thse resurces as a fully utsurced service. Sftware as a service (SaaS), smetimes referred t as "n-demand sftware," is a sftware delivery mdel in which sftware and its assciated data are hsted centrally (typically in the (Internet) clud) and are typically accessed by users using a thin client, nrmally using a web brwser ver the Internet. Platfrm as a service (PaaS), is the delivery f a cmputing platfrm and slutin stack as a service. PaaS fferings facilitate deplyment f applicatins withut the cst and cmplexity f buying and managing the underlying hardware and sftware and prvisining hsting capabilities. This prvides all f the facilities required t supprt the cmplete life cycle f building and delivering web applicatins and services entirely available frm the Internet CLOUD SECURITY ALLIANCE 15

17 PaaS sits n tp f IaaS and adds an additinal layer f integratin with applicatin develpment framewrks, middleware capabilities, and functins such as database, messaging, and queuing. These services allw develpers t build applicatins n the platfrm with prgramming languages and tls that are supprted by the stack. SaaS in turn is built upn the underlying IaaS and PaaS stacks and prvides a self-cntained perating envirnment that is used t deliver the entire user experience, including the cntent, its presentatin, the applicatin(s), and management capabilities. It shuld therefre be clear that there are significant trade-ffs t each mdel in terms f integrated features, cmplexity versus penness (extensibility), and security. Generally, SaaS prvides the mst integrated functinality built directly int the ffering, with the least cnsumer extensibility, and a relatively high level f integrated security (at least the prvider bears a respnsibility fr security). PaaS is intended t enable develpers t build their wn applicatins n tp f the platfrm. As a result, it tends t be mre extensible than SaaS, at the expense f custmer-ready features. This tradeff extends t security features and capabilities, where the built-in capabilities are less cmplete, but there is mre flexibility t layer n additinal security. IaaS prvides few if any applicatin-like features, but enrmus extensibility. This generally means less integrated security capabilities and functinality beynd prtecting the infrastructure itself. This mdel requires that perating systems, applicatins, and cntent be managed and secured by the clud cnsumer. The key takeaway fr security architecture is that the lwer dwn the stack the clud service prvider stps, the mre security capabilities and management cnsumers are respnsible fr implementing and managing themselves. Service levels, security, gvernance, cmpliance, and liability expectatins f the service and prvider are cntractually stipulated, managed t, and enfrced, when a service level agreement (SLA s) 6, is ffered t the cnsumer. There are tw types f SLA s, negtiable and nn-negtiable. In the absence f an SLA, the cnsumer administers all aspects f the clud under its cntrl. When a nn-negtiable SLA is ffered, the prvider administers thse prtins stipulated in the agreement. In the case f PaaS r IaaS, it is usually the respnsibility f the cnsumer s system administratrs t effectively manage the residual services specified in the SLA, with sme ffset expected by the prvider fr securing the underlying platfrm and infrastructure cmpnents t ensure basic service availability and security. It shuld be clear in all cases that ne can assign/transfer respnsibility but nt necessarily accuntability. Narrwing the scpe r specific capabilities and functinality within each f the clud delivery mdels, r emplying the functinal cupling f services and capabilities acrss them, may yield derivative classificatins. Fr example Strage as a Service is a specific sub-ffering within the IaaS family. While a brader review f the grwing set f clud cmputing slutins is utside the scpe f this dcument, the OpenCrwd Clud Slutins taxnmy in the figure belw prvides an excellent starting pint, hwever the CSA des nt specifically endrse any f the slutins r cmpanies shwn belw. It prvides the belw diagram t demnstrate the diversity f fferings available tday. 6 SLA - Service Level Agreement 2011 CLOUD SECURITY ALLIANCE 16

18 Figure 3 OpenCrwd Taxnmy 7 Fr an excellent verview f the many clud cmputing use cases, the Clud Cmputing Use Case Grup prduced a cllabrative wrk t describe and define cmmn cases and demnstrate the benefits f clud, with their gal being t...bring tgether clud cnsumers and clud vendrs t define cmmn use cases fr clud cmputing...and highlight CLOUD SECURITY ALLIANCE 17

19 the capabilities and requirements that need t be standardized in a clud envirnment t ensure interperability, ease f integratin, and prtability Clud Security Reference Mdel The clud security reference mdel addresses the relatinships f these classes and places them in cntext with their relevant security cntrls and cncerns. Fr rganizatins and individuals grappling with clud cmputing fr the first time, it is imprtant t nte the fllwing t avid ptential pitfalls and cnfusin: The ntin f hw clud services are deplyed is ften used interchangeably with where they are prvided, which can lead t cnfusin. Public r private cluds may be described as external r internal, which may nt be accurate in all situatins. The manner in which clud services are cnsumed is ften described relative t the lcatin f an rganizatin s management r security perimeter (usually defined by the presence f a knwn demarc). While it is still imprtant t understand where security bundaries lie in terms f clud cmputing, the ntin f a welldemarcated perimeter is an anachrnistic cncept fr mst rganizatins. The re-perimeterizatin and the ersin f trust bundaries already happening in the enterprise is amplified and accelerated by clud cmputing. Ubiquitus cnnectivity, the amrphus nature f infrmatin interchange, and the ineffectiveness f traditinal static security cntrls which cannt deal with the dynamic nature f clud services, all require new thinking with regard t clud cmputing. The Jerich Frum 8 has prduced a cnsiderable amunt f material n the re- perimeterizatin f enterprise netwrks, including many case studies. The deplyment and cnsumptin mdalities f clud shuld be thught f nt nly within the cntext f internal versus external as they relate t the physical lcatin f assets, resurces, and infrmatin; but als by whm they are being cnsumed; and wh is respnsible fr their gvernance, security, and cmpliance with plicies and standards. This is nt t suggest that the n- r ff-premise lcatin f an asset, a resurce, r infrmatin des nt affect the security and risk psture f an rganizatin because they d but t underscre that risk als depends upn: The types f assets, resurces, and infrmatin being managed Wh manages them and hw Which cntrls are selected and hw they are integrated Cmpliance issues Fr example, a LAMP 9 stack deplyed n Amazn s AWS EC2 wuld be classified as a public, ff-premise, third-party managed IaaS slutin, even if the instances and applicatins/data cntained within them were managed by the cnsumer r a third party. A custm applicatin stack serving multiple business units, deplyed n Eucalyptus under a LAMP-Linux (perating system), Apache HTTP Server, MySQL (database sftware) and Perl/PHP/Pythn, the principal cmpnents t build a viable general purpse web server 2011 CLOUD SECURITY ALLIANCE 18

20 crpratin s cntrl, management, and wnership, culd be described as a private, n-premise, self-managed SaaS slutin. Bth examples utilize the elastic scaling and self-service capabilities f clud. The fllwing table summarizes these pints: Table 1 Clud Cmputing Deplyment Mdels Anther way f visualizing hw cmbinatins f clud service mdels, deplyment mdels, physical lcatins f resurces, and attributin f management and wnership, is the Jerich Frum s Clud Cube Mdel 10, shwn in the figure t the right: The Clud Cube Mdel illustrates the many permutatins available in clud fferings tday and presents fur criteria/dimensins in rder t differentiate clud frmatins frm ne anther and the manner f their prvisin, in rder t understand hw clud cmputing affects the way in which security might be apprached. The Clud Cube Mdel als highlights the challenges f understanding and mapping clud mdels t cntrl framewrks and standards such as ISO/IEC 27002, which prvides...a series f guidelines and general principles fr initiating, 10 Figure 4 Jerich Clud Cube Mdel 2011 CLOUD SECURITY ALLIANCE 19

21 implementing, maintaining, and imprving infrmatin security management within an rganizatin. The ISO/IEC 27002, sectin 6.2, External Parties cntrl bjective states: the security f the rganizatin s infrmatin and infrmatin prcessing facilities shuld nt be reduced by the intrductin f external party prducts r services As such, the differences in methds and respnsibility fr securing the three clud service mdels mean that cnsumers f clud services are faced with a challenging endeavr. Unless clud prviders can readily disclse their security cntrls and the extent t which they are implemented t the cnsumer and the cnsumer knws which cntrls are needed t maintain the security f their infrmatin, there is tremendus ptential fr misguided risk management decisins and detrimental utcmes. First, ne classifies a clud service against the clud architecture mdel. Then it is pssible t map its security architecture as well as business, regulatry, and ther cmpliance requirements against it as a gap-analysis exercise. The result determines the general security psture f a service and hw it relates t an asset s assurance and prtectin requirements. The figure belw shws an example f hw a clud service mapping can be cmpared against a catalgue f cmpensating cntrls t determine which cntrls exist and which d nt as prvided by the cnsumer, the clud service prvider, r a third party. This can in turn be cmpared t a cmpliance framewrk r set f requirements such as PCI DSS, as shwn. Figure 5 Mapping the Clud Mdel t the Security Cntrl & Cmpliance 2011 CLOUD SECURITY ALLIANCE 20

22 Once this gap analysis is cmplete, per the requirements f any regulatry r ther cmpliance mandates, it becmes much easier t determine what needs t be dne in rder t feed back int a risk assessment framewrk. This, in turn, helps t determine hw the gaps and ultimately risks shuld be addressed: accepted, transferred, r mitigated. It is imprtant t nte that the use f clud cmputing as an peratinal mdel des nt inherently prvide fr r prevent achieving cmpliance. The ability t cmply with any requirement is a direct result f the service and deplyment mdel utilized and the design, deplyment, and management f the resurces in scpe. Fr an excellent verview f cntrl framewrks which prvides gd illustratins f the generic cntrl framewrk alluded t abve, see the Open Security Architecture Grup s 11 landscape f security architecture patterns dcumentatin, r the always useful and recently updated NIST revisin 3 Recmmended Security Cntrls fr Federal Infrmatin Systems and Organizatins security cntrl catalgue What Is Security fr Clud Cmputing? Security cntrls in clud cmputing are, fr the mst part, n different than security cntrls in any IT envirnment. Hwever, because f the clud service mdels emplyed, the peratinal mdels, and the technlgies used t enable clud services, clud cmputing may present different risks t an rganizatin than traditinal IT slutins. An rganizatin s security psture is characterized by the maturity, effectiveness, and cmpleteness f the risk-adjusted security cntrls implemented. These cntrls are implemented in ne r mre layers ranging frm the facilities (physical security), t the netwrk infrastructure (netwrk security), t the IT systems (system security), all the way t the infrmatin and applicatins (applicatin security). Additinally, cntrls are implemented at the peple and prcess levels, such as separatin f duties and change management, respectively. As described earlier in this dcument, the security respnsibilities f bth the prvider and the cnsumer greatly differ between clud service mdels. Amazn s AWS EC2 infrastructure as a service ffering, as an example, includes vendr respnsibility fr security up t the hypervisr, meaning they can nly address security cntrls such as physical security, envirnmental security, and virtualizatin security. The cnsumer, in turn, is respnsible fr security cntrls that relate t the IT system (instance) including the perating system, applicatins, and data. The inverse is true fr Salesfrce.cm s custmer resurce management (CRM) SaaS ffering. Because Salesfrce.cm prvides the entire stack, the prvider is nt nly respnsible fr the physical and envirnmental security cntrls, but it must als address the security cntrls n the infrastructure, the applicatins, and the data. This alleviates much f the cnsumer s direct peratinal respnsibility. There is currently n way fr a naive cnsumer f clud services t simply understand what exactly he/she is respnsible fr [thugh reading this guidance dcument shuld help], but there are effrts underway by the CSA and ther bdies t define standards arund clud audit. One f the attractins f clud cmputing is the cst efficiencies affrded by ecnmies f scale, reuse, and standardizatin. T bring these efficiencies t bear, clud prviders have t prvide services that are flexible enugh t serve the largest custmer base pssible, maximizing their addressable market. Unfrtunately, integrating security int these slutins is ften perceived as making them mre rigid CLOUD SECURITY ALLIANCE 21

23 This rigidity ften manifests in the inability t gain parity in security cntrl deplyment in clud envirnments cmpared t traditinal IT. This stems mstly frm the abstractin f infrastructure, and the lack f visibility and capability t integrate many familiar security cntrls, especially at the netwrk layer. The figure belw illustrates these issues: in SaaS envirnments the security cntrls and their scpe are negtiated int the cntracts fr service; service levels, privacy, and cmpliance are all issues t be dealt with legally in cntracts. In an IaaS ffering, while the respnsibility fr securing the underlying infrastructure and abstractin layers belngs t the prvider, the remainder f the stack is the cnsumer s respnsibility. PaaS ffers a balance smewhere in between, where securing the platfrm falls nt the prvider, but bth securing the applicatins develped against the platfrm and develping them securely, belng t the cnsumer. Figure 6 Hw Security Gets Integrated Understanding the impact f these differences between service mdels and hw they are deplyed is critical t managing the risk psture f an rganizatin CLOUD SECURITY ALLIANCE 22

24 1.5.3 Beynd Architecture: The Areas f Critical Fcus The thirteen ther dmains which cmprise the remainder f the CSA guidance highlight areas f cncern fr clud cmputing and are tuned t address bth the strategic and tactical security pain pints within a clud envirnment and can be applied t any cmbinatin f clud service and deplyment mdel. The dmains are divided int tw brad categries: gvernance and peratins. The gvernance dmains are brad and address strategic and plicy issues within a clud cmputing envirnment, while the peratinal dmains fcus n mre tactical security cncerns and implementatin within the architecture. Table 2a Gvernance Dmains DOMAIN Gvernance and Enterprise Risk Management Legal Issues: Cntracts and Electrnic Discvery Cmpliance and Audit Infrmatin Management and Data Security Prtability and Interperability GUIDANCE DEALING WITH The ability f an rganizatin t gvern and measure enterprise risk intrduced by clud cmputing. Items such as legal precedence fr agreement breaches, ability f user rganizatins t adequately assess risk f a clud prvider, respnsibility t prtect sensitive data when bth user and prvider may be at fault, and hw internatinal bundaries may affect these issues. Ptential legal issues when using clud cmputing. Issues tuched n in this sectin include prtectin requirements fr infrmatin and cmputer systems, security breach disclsure laws, regulatry requirements, privacy requirements, internatinal laws, etc. Maintaining and prving cmpliance when using clud cmputing. Issues dealing with evaluating hw clud cmputing affects cmpliance with internal security plicies, as well as varius cmpliance requirements (regulatry, legislative, and therwise) are discussed here. This dmain includes sme directin n prving cmpliance during an audit. Managing data that is placed in the clud. Items surrunding the identificatin and cntrl f data in the clud, as well as cmpensating cntrls that can be used t deal with the lss f physical cntrl when mving data t the clud, are discussed here. Other items, such as wh is respnsible fr data cnfidentiality, integrity, and availability are mentined. The ability t mve data/services frm ne prvider t anther, r bring it entirely back in-huse. Tgether with issues surrunding interperability between prviders CLOUD SECURITY ALLIANCE 23

25 Table 2b - Operatinal Dmains SECURITY GUIDANCE FOR CRITICAL AREAS OF DOMAIN Traditinal Security, Business Cntinuity and Disaster Recvery Data Center Operatins Incident Respnse, Ntificatin and Remediatin Applicatin Security Encryptin and Key Management Identity and Access Management Virtualizatin GUIDANCE DEALING WITH Hw clud cmputing affects the peratinal prcesses and prcedures currently used t implement security, business cntinuity, and disaster recvery. The fcus is t discuss and examine pssible risks f clud cmputing, in hpes f increasing dialgue and debate n the verwhelming demand fr better enterprise risk management mdels. Further, the sectin tuches n helping peple t identify where clud cmputing may assist in diminishing certain security risks, r entails increases in ther areas. Hw t evaluate a prvider s data center architecture and peratins. This is primarily fcused n helping users identify cmmn data center characteristics that culd be detrimental t n-ging services, as well as characteristics that are fundamental t lng-term stability. Prper and adequate incident detectin, respnse, ntificatin, and remediatin. This attempts t address items that shuld be in place at bth prvider and user levels t enable prper incident handling and frensics. This dmain will help yu understand the cmplexities the clud brings t yur current incident-handling prgram. Securing applicatin sftware that is running n r being develped in the clud. This includes items such as whether it s apprpriate t migrate r design an applicatin t run in the clud, and if s, what type f clud platfrm is mst apprpriate (SaaS, PaaS, r IaaS). Identifying prper encryptin usage and scalable key management. This sectin is nt prescriptive, but is mre infrmatinal in discussing why they are needed and identifying issues that arise in use, bth fr prtecting access t resurces as well as fr prtecting data. Managing identities and leveraging directry services t prvide access cntrl. The fcus is n issues encuntered when extending an rganizatin s identity int the clud. This sectin prvides insight int assessing an rganizatin s readiness t cnduct clud-based Identity, Entitlement, and Access Management (IdEA). The use f virtualizatin technlgy in clud cmputing. The dmain addresses items such as risks assciated with multi-tenancy, VM islatin, VM cresidence, hypervisr vulnerabilities, etc. This dmain fcuses n the security issues surrunding system/hardware virtualizatin, rather than a mre general survey f all frms f virtualizatin CLOUD SECURITY ALLIANCE 24

26 Security as a Service Prviding third party facilitated security assurance, incident management, cmpliance attestatin, and identity and access versight. Security as a service is the delegatin f detectin, remediatin, and gvernance f security infrastructure t a trusted third party with the prper tls and expertise. Users f this service gain the benefit f dedicated expertise and cutting edge technlgy in the fight t secure and harden sensitive business peratins. 1.6 Clud Deplyment Mdels Regardless f the service mdel utilized (SaaS, PaaS, r IaaS), there are fur deplyment mdels fr clud services with derivative variatins that address specific requirements. It is imprtant t nte that there are derivative clud deplyment mdels emerging due t the maturatin f market fferings and custmer demand. An example f such is virtual private cluds a way f utilizing public clud infrastructure in a private r semi-private manner and intercnnecting these resurces t the internal resurces f a cnsumer s datacenter, usually via virtual private netwrk (VPN) cnnectivity. The architectural mind-set used when designing slutins has clear implicatins n the future flexibility, security, and mbility f the resultant slutin, as well as its cllabrative capabilities. As a rule f thumb, perimeterized slutins are less effective than de-perimeterized slutins in each f the fur areas. Careful cnsideratin shuld als be given t the chice between prprietary and pen slutins fr similar reasns. Deplyment mdels Public Clud. The clud infrastructure is made available t the general public r a large industry grup and is wned by an rganizatin selling clud services. Private Clud. The clud infrastructure is perated slely fr a single rganizatin. It may be managed by the rganizatin r by a third party and may be lcated n-premise r ff-premise. Cmmunity Clud. The clud infrastructure is shared by several rganizatins and supprts a specific cmmunity that has shared cncerns (e.g., missin, security requirements, plicy, r cmpliance cnsideratins). It may be managed by the rganizatins r by a third party and may be lcated n-premise r ff-premise. Hybrid Clud. The clud infrastructure is a cmpsitin f tw r mre cluds (private, cmmunity, r public) that remain unique entities but are bund tgether by standardized r prprietary technlgy that enables data and applicatin prtability (e.g., clud bursting fr lad-balancing between cluds) CLOUD SECURITY ALLIANCE 25

27 1.7 Recmmendatins Clud service delivery is divided amng three archetypal mdels and varius derivative cmbinatins. The three fundamental classificatins are ften referred t as the SPI Mdel, where SPI refers t Sftware, Platfrm r Infrastructure (as a Service), respectively. Clud Sftware as a Service (SaaS). The capability prvided t the cnsumer is t use the prvider s applicatins running n a clud infrastructure. The applicatins are accessible frm varius client devices thrugh a thin client interface such as a web brwser (e.g., web-based ). The cnsumer des nt manage r cntrl the underlying clud infrastructure including netwrk, servers, perating systems, strage, r even individual applicatin capabilities with the pssible exceptin f limited user-specific applicatin cnfiguratin settings. Clud Platfrm as a Service (PaaS). The capability prvided t the cnsumer is t deply nt the clud infrastructure cnsumer-created r acquired applicatins created using prgramming languages and tls supprted by the prvider. The cnsumer des nt manage r cntrl the underlying clud infrastructure including netwrk, servers, perating systems, r strage, but has cntrl ver the deplyed applicatins and pssibly applicatin hsting envirnment cnfiguratins. Clud Infrastructure as a Service (IaaS). The capability prvided t the cnsumer is t prvisin prcessing, strage, netwrks, and ther fundamental cmputing resurces where the cnsumer is able t deply and run arbitrary sftware, which culd include perating systems and applicatins. The cnsumer des nt manage r cntrl the underlying clud infrastructure but has cntrl ver perating systems, strage, deplyed applicatins, and pssibly limited cntrl f select netwrking cmpnents (e.g., hst firewalls). The NIST mdel and this dcument d nt directly address the emerging service mdel definitins assciated with clud service brkers, thse prviders that ffer intermediatin, mnitring, transfrmatin/prtability, gvernance, prvisining, and integratin services and negtiate relatinships between varius clud prviders and cnsumers. In the shrt term, as innvatin drives rapid slutin develpment, cnsumers and prviders f clud services will enjy varied methds f interacting with clud services in the frm f develping API s and interfaces and s clud service brkers will emerge as an imprtant cmpnent in the verall clud ecsystem. Clud service brkers will abstract these pssibly incmpatible capabilities and interfaces n behalf f cnsumers t prvide prxy in advance f the arrival f cmmn, pen, and standardized ways f slving the prblem lnger term with a semantic capability that allws the cnsumer a fluidity and agility in being able t take advantage f the mdel that wrks best fr their particular needs. It is als imprtant t nte the emergence f many effrts centered n the develpment f bth pen and prprietary API s, which seek t enable things such as management, security, and interperability fr clud. Sme f these effrts include the Open Clud Cmputing Interface Wrking Grup, Amazn EC2 API, VMware s DMTF-submitted vclud API, Sun s Open Clud API, Rackspace API, and GGrid s API, t name just a few. Open, standard API s will play a key rle in clud prtability and interperability as well as cmmn cntainer frmats such as the DMTF s Open Virtualizatin Frmat (OVF) CLOUD SECURITY ALLIANCE 26

28 While there are many wrking grups, drafts, and published specificatins under cnsideratin at this time, it is natural that cnslidatin will take effect as market frces, cnsumer demand, and ecnmics pare dwn this landscape t a mre manageable and interperable set f players. 1.8 Requirements Clud services exhibit five essential characteristics that demnstrate their relatin t, and differences frm, traditinal cmputing appraches. On-demand self-service. A cnsumer can unilaterally prvisin cmputing capabilities such as server time and netwrk strage as needed autmatically withut requiring human interactin with a service prvider. Brad netwrk access. Capabilities are available ver the netwrk and accessed thrugh standard mechanisms that prmte use by hetergeneus thin r thick client platfrms (e.g., mbile phnes, laptps, and PDA s) 12 as well as ther traditinal r clud-based sftware services. Resurce pling. The prvider s cmputing resurces are pled t serve multiple cnsumers using a multitenant mdel with different physical and virtual resurces dynamically assigned and reassigned accrding t cnsumer demand. There is a degree f lcatin independence in that the custmer generally has n cntrl r knwledge ver the exact lcatin f the prvided resurces, but may be able t specify lcatin at a higher level f abstractin (e.g., cuntry, state, r datacenter). Examples f resurces include strage, prcessing, memry, netwrk bandwidth, and virtual machines. Even private cluds tend t pl resurces between different parts f the same rganizatin. Rapid elasticity. Capabilities can be rapidly and elastically prvisined in sme cases autmatically t quickly scale ut; and rapidly released t quickly scale in. T the cnsumer, the capabilities available fr prvisining ften appear t be unlimited and can be purchased in any quantity at any time. Measured service. Clud systems autmatically cntrl and ptimize resurce usage by leveraging a metering capability at sme level f abstractin apprpriate t the type f service (e.g., strage, prcessing, bandwidth, r active user accunts). Resurce usage can be mnitred, cntrlled, and reprted prviding transparency fr bth the prvider and cnsumer f the service. The keys t understanding hw clud architecture impacts security architecture are a cmmn and cncise lexicn cupled with a cnsistent taxnmy f fferings by which clud services and architecture can be decnstructed, mapped t a mdel f cmpensating security and peratinal cntrls, risk assessment framewrks, and management framewrks; and in turn t cmpliance standards. Understanding hw architecture, technlgy, prcess, and human capital requirements change r remain the same when deplying clud-cmputing services is critical. Withut a clear understanding f the higher-level architectural implicatins, it is impssible t address mre detailed issues ratinally. This architectural verview, alng with the thirteen ther areas f critical fcus, will prvide the reader with a slid fundatin fr assessing, peratinalizing, managing, and gverning security in clud cmputing envirnments. 12 PDA - Persnal Digital Assistant 2011 CLOUD SECURITY ALLIANCE 27

29 REFERENCES [1] NIST definitin f Clud. NIST NIST Clud Cmputing Reference Architecture [2] NIST definitins and API hmepages. [3] Jerich Frum Clud Cube Mdel CLOUD SECURITY ALLIANCE 28

30 SECTION II // GOVERNING IN THE CLOUD 2011 CLOUD SECURITY ALLIANCE 29

31 DOMAIN 2 // GOVERNANCE & ENTERPRISE RISK MANAGEMENT SECURITY GUIDANCE FOR CRITICAL AREAS OF The fundamental issues f gvernance and enterprise risk management in clud cmputing cncern the identificatin and implementatin f the apprpriate rganizatinal structures, prcesses, and cntrls t maintain effective infrmatin security gvernance, risk management, and cmpliance. Organizatins shuld als assure reasnable infrmatin security acrss the infrmatin supply chain, encmpassing prviders and custmers f clud cmputing services and their supprting third party vendrs, in any clud deplyment mdel. An effective gvernance and enterprise risk management clud cmputing prgram flws frm well-develped infrmatin security gvernance prcesses as part f the rganizatin s verall crprate gvernance bligatins f due care. Well-develped infrmatin security gvernance prcesses result in infrmatin security management prgrams that are scalable with the business, repeatable acrss the rganizatin, measurable, sustainable, defensible, cntinually imprving, and cst-effective n an nging basis. Fr many clud deplyments, a majr element f gvernance will be the agreement between prvider and custmer. Fr custm envirnments, detailed care can be taken, and negtiated, fr each prvisin. Fr larger scale custmer r prviders, there will be a decisin whether t trade ff attentin t detail vs. scalability f effrt. Attentin can be priritized base n criticality r value at risk fr the particular wrklad (e.g., up-time and availability may be mre imprtant fr than fr HR systems). As the space cntinues t mature, prjects like Clud Audit r STAR will prvide mre standardized gvernance methds, therefre greater scalability. Overview. This dmain addresses: Gvernance Enterprise Risk Management 2.1 Crprate Gvernance This sectin maps t the Clud Cntrl Matrix Cntrls DG-01, IS-02 and the use f GRC-XML and CludAudit t establish slvency. Crprate gvernance is the set f prcesses, technlgies, custms, plicies, laws, and institutins affecting the way an enterprise is directed, administered r cntrlled. Crprate gvernance als includes the relatinship amng the many stakehlders invlved and the gals f the cmpany invlved. Gd gvernance is based n the acceptance f the rights f sharehlders, as the true wners f the crpratin, and the rle f senir management as trustees. There are many mdels f crprate gvernance; hwever, all fllw five basic principles: Auditing supply chains Bard and management structure and prcess Crprate respnsibility and cmpliance Financial transparency and infrmatin disclsure 2011 CLOUD SECURITY ALLIANCE 30

32 Ownership structure and exercise f cntrl rights A key factr in a custmer decisin t engage a crpratin is the cnfidence that expectatins will be met. Fr clud services, the interdependencies amng multiple services make it mre difficult fr a custmer t srt ut the respnsible party. If that results in less cnfidence in a particular vendr, then further engagement with that vendr is less likely. If this becmes a systemic feature, the lss f cnfidence in ne actr will rllver t thers, and the market failure will increase the likelihd f bth external actin and alternative participants. Stakehlders shuld carefully cnsider the mnitring mechanisms that are apprpriate and necessary fr the cmpany s cnsistent perfrmance and grwth. 2.2 Enterprise Risk Management Enterprise risk management (ERM) is rted in the cmmitment by every rganizatin t prvide value fr its stakehlders. All businesses face uncertainty and ne f management s challenges is t determine hw ne rganizatin can measure, manage, and mitigate that uncertainty. Uncertainty presents bth pprtunity and risk with ptential t increase r decrease the value f the rganizatin and its strategies. Infrmatin risk management is the prcess f identifying and understanding expsure t risk and capability f managing it, aligned with the risk appetite and tlerance f the data wner. Hence, it is the primary means f decisin supprt fr IT resurces dedicated t delivering the cnfidentiality, integrity, and availability f infrmatin assets. Enterprise risk management in business includes the methds and prcesses used by rganizatins t manage risks and seize pprtunities related t the achievement f their bjectives. In a clud envirnment, management selects a risk respnse strategy fr specific risks identified and analyzed, which may include: Avidance exiting the activities giving rise t risk Reductin taking actin t reduce the likelihd r impact related t the risk Share r insure transferring r sharing a prtin f the risk t finance it Accept n actin is taken due t a cst/benefit decisin Risk management is naturally a balancing prcess with the gal nt necessarily t minimize uncertainty r variatin, but rather the gal f maximizing value in line with risk appetite and strategy. There are many variables, values, and risk in any clud pprtunity r prgram that affect the decisin whether a clud service shuld be adpted frm a risk r business value standpint. Each enterprise has t weigh thse variables t decide whether the clud is an apprpriate slutin. Clud cmputing ffers enterprises many pssible benefits, sme f these benefits include: Optimized resurce utilizatin This sectin maps t the Clud Cntrl Matrix Cntrls DG-08 and the use f ISO31000, ISF and ISACA guidelines t establish slvency CLOUD SECURITY ALLIANCE 31

33 Cst savings fr clud cmputing tenants Transitining f capital expenses (CAPEX) t perating expenses (OPEX) Dynamic scalability f IT pwer fr clients Shrtened life cycle develpment f new applicatins r deplyments Shrtened time requirements fr new business implementatin Custmers shuld view clud services and security as supply chain security issues. This means examining and assessing the prvider s supply chain (service prvider relatinships and dependencies) t the extent pssible. This als means examining the prvider s wn third party management. Assessment f third party service prviders shuld specifically target the prvider s incident management, business cntinuity and disaster recvery plicies, and prcesses and prcedures; and shuld include review f c-lcatin and back-up facilities. This shuld include review f the prvider s internal assessments f cnfrmance t its wn plicies and prcedures and assessment f the prvider s metrics t prvide reasnable infrmatin regarding the perfrmance and effectiveness f its cntrls in these areas. Incident infrmatin can be specified in cntracts, SLAs, r ther jint agreements, and can be cmmunicated autmatically r peridically, directly int reprting systems r delivered t key persnnel. The level f attentin and scrutiny shuld be cnnected t the value at risk if the third party will nt directly access enterprise data, then the level f risk drps significantly and vice versa. Custmers shuld review the risk management prcesses and gvernance f their prviders, and ensure that practices are cnsistent and aligned. 2.3 Permissins Permissins Adpt an established risk framewrk fr mnitring and measuring crprate risk Adpt metrics t measure risk management perfrmance (e.g., Security Cntent Autmatin Prtcl (SCAP) 13, Cybersecurity Infrmatin Exchange Framewrk (CYBEX) 14, r GRC-XML 15 ). Adpt a risk centric viewpint f crprate gvernance with senir management taking the rle f trustee fr bth the sharehlders and the stakehlders in the supply chain. Adpt a framewrk frm legal perspective t accunt fr differences acrss jurisdictins. 13 SCAP - Security Cntent Autmatin Prtcl 14 CYBEX - Cybersecurity Infrmatin Exchange Framewrk 15 GRC-XML - technlgy standards t enable and enhance the sharing f infrmatin between varius technlgies that supprt GRC effrts 2011 CLOUD SECURITY ALLIANCE 32

34 2.4 Recmmendatins Reinvest the cst savings btained by clud cmputing services int increased scrutiny f the security capabilities f the prvider, applicatin f security cntrls, and nging detailed assessments and audits t ensure requirements are cntinuusly met. User rganizatins shuld include review f specific infrmatin security gvernance structure and prcesses, as well as specific security cntrls, as part f their due diligence fr prspective prvider rganizatins. The prvider s security gvernance prcesses and capabilities shuld be assessed fr sufficiency, maturity, and cnsistency with the user s infrmatin security management prcesses. The prvider s infrmatin security cntrls shuld be demnstrably risk-based and clearly supprt these management prcesses. Cllabrative gvernance structures and prcesses between custmers and prviders shuld be identified as necessary, bth as part f the design and develpment f service delivery, and as service risk assessment and risk management prtcls, and then incrprated int service agreements. Security departments shuld be engaged during the establishment f Service Level Agreements (SLA s) 16 and cntractual bligatins t ensure that security requirements are cntractually enfrceable. Metrics and standards fr measuring perfrmance and effectiveness f infrmatin security management shuld be established prir t mving int the clud. At a minimum, rganizatins shuld understand and dcument their current metrics and hw they will change when peratins are mved int the clud and where a prvider may use different (ptentially incmpatible) metrics. Due t the lack f physical cntrl ver infrastructure by custmers, in many Clud Cmputing deplyments, SLA s, cntract requirements, and prvider dcumentatin play a larger rle in risk management than with traditinal, enterprise wned infrastructure. Due t the n-demand prvisining and multi-tenant aspects f clud cmputing, traditinal frms f audit and assessment may nt be available r may be mdified. Fr example, sme prviders restrict vulnerability assessments and penetratin testing, while thers limit availability f audit lgs and activity mnitring. If these are required per yur internal plicies, yu may need t seek alternative assessment ptins, specific cntractual exceptins, r an alternative prvider better aligned with yur risk management requirements. If the services prvided in the clud are essential t crprate peratins a risk management apprach shuld include identificatin and valuatin f assets, identificatin and analysis f threats and vulnerabilities and their ptential impact n assets (risk and incident scenaris), analysis f the likelihds f events/scenaris, management-apprved risk acceptance levels and criteria, and the develpment f risk treatment plans with multiple ptins (cntrl, avid, transfer, accept). The utcmes f risk treatment plans shuld be incrprated int service agreements. Risk assessment appraches between prvider and user shuld be cnsistent with cnsistency in impact analysis criteria and definitin f likelihd. The user and prvider shuld jintly develp risk scenaris fr the clud service; this shuld be intrinsic t the prvider s design f service fr the user, and t the user s assessment f clud service risk. 16 SLA - Service Level Agreement 2011 CLOUD SECURITY ALLIANCE 33

35 Due t the evlving nature f clud and its prviders, care shuld be taken t include vendr risk, e.g., business survivability f prviders, prtability f data and applicatins, and interperability f services. Asset inventries shuld accunt fr assets supprting clud services and under the cntrl f the prvider. Asset classificatin and valuatin schemes shuld be cnsistent between user and prvider. The service, and nt just the vendr, shuld be the subject f risk assessment. The use f clud services, and the particular service and deplyment mdels t be utilized, shuld be cnsistent with the risk management bjectives f the rganizatin, as well as with its business bjectives. Clud Cmputing service custmers and prviders shuld develp rbust infrmatin security gvernance, regardless f the service r deplyment mdel. Infrmatin security gvernance shuld be cllabratin between custmers and prviders t achieve agreed-upn gals that supprt the business missin and infrmatin security prgram. Gvernance shuld include peridic review, and the service mdel may adjust the defined rles and respnsibilities in cllabrative infrmatin security gvernance and risk management (based n the respective scpe f cntrl fr user and prvider), while the deplyment mdel may define accuntability and expectatins (based n risk assessment). Custmers f clud services shuld ask whether their wn management has defined risk tlerances with respect t clud services and accepted any residual risk f utilizing clud services. Where a prvider cannt demnstrate cmprehensive and effective risk management prcesses in assciatin with its services, custmers shuld carefully evaluate use f the vendr as well as the user s wn abilities t cmpensate fr the ptential risk management gaps. Organizatins shuld define risk metrics fr engaging prviders based n business and technical expsures. These metrics culd include the type f data cvered, the variety f user types relating t the infrmatin, and the vendrs and ther cunterparties invlved. 2.5 Requirements Prvide transparency t stakehlders and sharehlders demnstrating fiscal slvency and rganizatinal transparency. Respect the interdependency f the risks inherent in the clud supply chain and cmmunicate the crprate risk psture and readiness t cnsumers and dependant parties. Inspect and accunt fr risks inherited frm ther members f the clud supply chain and take active measures t mitigate and cntain risks thrugh peratinal resiliency CLOUD SECURITY ALLIANCE 34

36 DOMAIN 3 // LEGAL ISSUES: CONTRACTS AND ELECTRONIC DISCOVERY SECURITY GUIDANCE FOR CRITICAL AREAS OF This dmain highlights sme f the legal aspects raised by clud cmputing. It prvides general backgrund n legal issues that can be raised by mving data t the clud, sme issues fr cnsideratin in a clud services agreement, and the special issues presented by electrnic discvery under Western litigatin. This dmain prvides an verview f selected issues and it is nt a substitute fr btaining legal advice. Overview. This dmain will address the fllwing tpics: Summary f specific legal issues raised by mving data t the clud Cnsideratins fr a clud services agreement Special issues raised by e-discvery 3.1 Legal Issues In many cuntries thrughut the wrld, numerus laws, regulatins, and ther mandates require public and private rganizatins t prtect the privacy f persnal data and the security f infrmatin and cmputer systems. Fr example, in the Asia Pacific regin, Japan, Australia, New Zealand, and many thers have adpted data prtectin laws that require the data cntrller t adpt reasnable technical, physical, and administrative measures in rder t prtect persnal data frm lss, misuse, r alteratin, based n the Privacy and Security Guidelines f the Organizatin fr Ecnmic Cperatin and Develpment (OECD) 17, and the Asia Pacific Ecnmic Cperatin s (APEC) 18 Privacy Framewrk. In Eurpe, the Eurpean Ecnmic Area (EEA) 19 Member States have enacted data prtectin laws that fllw the principles set frth in the 1995 Eurpean Unin (EU) Data Prtectin Directive 20 and the 2002 eprivacy Directive (as amended in 2009). These laws include a security cmpnent, and the bligatin t prvide adequate security must be passed dwn t subcntractrs. Other cuntries that have clse ties with the EEA, such as Mrcc and Tunisia in Africa, Israel and Dubai in the Middle East have als adpted similar laws that fllw the same principles. Nrth, Central, and Suth America cuntries are als adpting data prtectin laws at a rapid pace. Each f these laws includes a security requirement and places n the data custdian the burden f ensuring the prtectin and security f persnal data wherever the data are lcated, and especially when transferring t a third party. Fr example, in additin t the data prtectin laws f Canada, Argentina and Clmbia, which have been in existence fr several years, Mexic, Uruguay, and Peru have recently passed data prtectin laws that are inspired mainly frm the Eurpean mdel and may include references t the APEC Privacy Framewrk as well. 17 OECD - Organizatin fr Ecnmic Cperatin and Develpment 18 APEC - Asia Pacific Ecnmic Cperatin 19 EEA - Eurpean Ecnmic Area 20 EU Directive 95/46/EC 2011 CLOUD SECURITY ALLIANCE 35

37 In Japan, the Persnal Infrmatin Prtectin Act requires the private sectrs t prtect persnal infrmatin and data securely. In the healthcare industry, prfessin-specific laws, such as the Medical Practitiners' Act, the Act n Public Health Nurses, Midwives and Nurses, and the Pharmacist Act, require registered health prfessinals fr cnfidentiality f patient infrmatin. Organizatins that d business in the United States may be subject t ne r mre data prtectin laws. The laws hld rganizatins respnsible fr the acts f their subcntractrs. Fr example, the security and privacy rules under the Gramm-Leach-Bliley Act (GLBA) 21 r the Health Insurance Prtability and Accuntability Act f 1996 (HIPAA) require that rganizatins cmpel their subcntractrs, in written cntracts, t use reasnable security measures and cmply with data privacy prvisins. Gvernment agencies, such as the Federal Trade Cmmissin (FTC) r the State Attrneys General have cnsistently held rganizatins liable fr the activities f their subcntractrs. The Payment Card Industry (PCI) Data Security Standards (DSS), which apply t credit card data anywhere in the wrld, including data prcessed by subcntractrs has similar requirements. The fllwing sectins prvide examples f legal issues that may arise in cnnectin with the transfer f persnal data t the clud r the prcessing f persnal data in the clud. Table 1 Obligatry Predicates ISSUE U.S. Federal Laws U.S. State Laws Standards Internatinal Regulatins DESCRIPTION Numerus federal laws and their related regulatins, such as GLBA, HIPAA, Children s Online Privacy Prtectin Act f 1998 ( COPPA ), tgether with rders issued by the FTC, require cmpanies t adpt specific privacy and security measures when prcessing data, t require similar precautins in their cntracts with the third party service prvider. Numerus state laws als create an bligatin n cmpanies t prvide adequate security fr persnal data and t require their service prviders t d the same. State laws that address infrmatin security issues generally require, at a minimum, that the cmpany have a written cntract with the service prvider with reasnable security measures. See fr example the extensive requirements under the Massachusetts Security Regulatins. Standards such as PCI DSS r ISO als create a dmin effect similar t that f federal and state laws. Cmpanies that are subject t PCI DSS r ISO must bth cmply with specified standards and pass nt their subcntractrs the same bligatin t meet the standard t which they are subject. Many cuntries have adpted data prtectin laws that fllw the Eurpean Unin mdel, the OECD mdel r the APEC mdel. Under these laws, the data cntrller (typically the entity that has the primary relatinship with an individual) remains respnsible fr the cllectin and prcessing f persnal data, even when third parties prcess the data. The data cntrller is required t ensure that any third party 21 GLBA - Gramm-Leach-Billey Act 2011 CLOUD SECURITY ALLIANCE 36

38 prcessing persnal data n its behalf takes adequate technical and rganizatinal security measures t safeguard the data. Even if a specific activity is nt regulated, cmpanies may have a cntractual bligatin t prtect the persnal infrmatin f their clients, cntacts r emplyees, t ensure that the data are nt used fr secndary uses, and are nt disclsed t third parties. This bligatin may stem, fr example, frm the Terms and Cnditins and Privacy Statement that a cmpany pst n its website. Cntractual Obligatins Alternately, the cmpany may have entered int cntracts (such as service agreements) with its custmers, in which it has made specific cmmitments t prtect the data (persnal data r cmpany data), limit their use, ensure their security, use encryptin, etc. The rganizatin must ensure that, when data in its custdy are hsted in the clud, it will have the cntinued ability t meet the prmises and cmmitments that it made in its privacy ntice(s) r ther cntracts. Fr example, the cmpany may have agreed t make nly specific uses f the data. Data in the clud must be used nly fr the purpses fr which they were cllected. If the privacy ntice allws individual data subjects t have access t their persnal data, and t have this infrmatin mdified r deleted, the clud service prvider must als allw these access, mdificatin and deletin rights t be exercised t the same extent as it wuld in a nn-clud relatinship. Prhibitin against crss brder transfers Many laws, thrughut the wrld, prhibit r restrict the transfer f infrmatin ut f the cuntry. In mst cases, the transfer is permitted nly if the cuntry t which the data are transferred ffers an adequate prtectin f persnal infrmatin and privacy rights. The purpse f this adequacy requirement is t ensure that the individual data subjects whse data are transferred acrss brders will be able t enjy, in the new cuntry where their data were transferred, privacy rights and privacy prtectins that are similar t, and nt less than, thse that were affrded t them befre the transfer. Thus, it is imprtant fr a clud user t knw where the persnal data f its emplyees, clients, and thers will be lcated, s that it can address the specific restrictins that freign data prtectin laws may impse. Depending n the cuntry, the requirements fr ensuring this adequate prtectin may be cmplex and stringent. In sme cases, it may be necessary t btain prir permissin f the lcal Data Prtectin Cmmissiner. 3.2 Cntract Cnsideratins When data is transferred t a clud, the respnsibility fr prtecting and securing the data typically remains with the cllectr r custdian f that data, even if in sme circumstances, this respnsibility may be shared with thers. When it relies n a third party t hst r prcess its data, the custdian f the data remains liable fr any lss, damage, r 2011 CLOUD SECURITY ALLIANCE 37

39 misuse f the data. It is prudent, and may be legally required, that the data custdian and the clud prvider enter int a written (legal) agreement that clearly defines the rles, expectatins f the parties, and allcates between them the many respnsibilities that are attached t the data at stake. The laws, regulatins, standards and the related best practices discussed abve, als require data custdians t ensure that these bligatins will be fulfilled by cnducting due diligence (befre executin f the cntract) r security audits (during perfrmance f the cntract) Due Diligence Befre entering int a clud cmputing arrangement, a cmpany shuld evaluate its wn practices, needs, and restrictins, in rder t identify the legal barriers and cmpliance requirements, assciated with a prpsed clud cmputing transactin. Fr example, it shuld determine whether its business mdel allws fr the use f clud cmputing services, and under which cnditins. The nature f its business might be such that any relinquishment f cntrl ver the cmpany data is restricted by law r creates serius security cncerns. In additin, the cmpany shuld and in sme cases may be legally required t cnduct due diligence f the prpsed clud service prvider, in rder t determine whether the ffering will allw the cmpany t fulfill its cntinued bligatin t prtect its assets Cntract The parties must enter int a written cntract. Depending n the nature f the services, the cntract may cmmnly be in the frm f a click-wrap agreement, which is nt negtiated; r the parties may negtiate a mre cmplex written dcument that is tailred t the specific situatin. If a click-wrap agreement is the nly agreement available, the clud service client shuld balance the risks frm freging negtiatins against the actual benefits, financial savings, and ease f use prmised by the clud service prvider. If the parties can negtiate a cntract, they shuld ensure that the prvisins f this cntract address the needs and bligatins f the parties bth during the term f the cntract and upn terminatin. Detailed, cmprehensive prvisins, addressing the unique needs and risks f perating in a clud envirnment, shuld be negtiated. If issues are nt addressed in the cntract, the clud service custmer shuld cnsider alternate means f achieving the gal, an alternate prvider, r nt sending the data t the clud. Fr example, if the clud service custmer wishes t send HIPAA-cvered infrmatin t the clud, the custmer will need t find a clud service prvider that will sign a HIPAA business assciate agreement r else nt send that data t the clud. Belw are brief descriptins f sme clud-specific issues. In additin, the attached checklist prvides a cmprehensive (but nt exhaustive) list f issues t cnsider when reviewing a clud services cntract Mnitring, Testing and Updating The clud envirnment is nt static. It evlves, and the parties must adapt. Peridic mnitring, testing, and evaluatin f the services are recmmended, in rder t ensure that the required privacy and security measures are being used, and the prcesses and plicies are being fllwed CLOUD SECURITY ALLIANCE 38

40 In additin, the legal, regulatry, and technical landscape is likely t change at a rapid pace. New security threats, new laws, new cmpliance requirements must be addressed prmptly. The parties must keep abreast f the legal and ther requirements and ensure that the peratins remain cmpliant with applicable laws, and that the security measures in place keep evlving as new technlgies and new laws emerge. Clud Audit and Clud Trust Prtcl are tw mechanisms t autmate mnitring and testing f clud supply chains. In additin, the ITU-T is wrking n an X.1500 Clud Auditing specificatin referred t as CYBEX. 3.3 Special Issues Raised by E-Discvery This sectin addresses the unique requirements f litigatin in the United States. U.S. litigants rely heavily n dcuments when arguing their case. One f the particularities f the American judicial system in great cntrast t mst ther cuntries is that a US litigant must prvide its adversary with ALL dcuments that pertain t the case. It must nt nly prvide the dcuments that are favrable t its case, but als the dcuments that are favrable t the ther litigant. In recent years, there have been numerus scandals where litigants were accused t have vluntarily deleted, lst, r mdified imprtant evidence that was detrimental t their case. As a result, the rules f prcedures have been changed t clarify the bligatins f the parties, especially in the case f electrnically stred infrmatin r ESI. Since the clud will becme the repsitry f mst ESI that is needed in a litigatin r investigatin, clud service prviders and their clients must carefully plan hw they will be able t identify all dcuments that pertain t a case in rder t be able t fulfill the stringent requirements impsed by the E-Discvery prvisins f the Federal Rules f Civil Prcedure, and the State equivalents t these laws. In this regard, the clud service client and prvider need t cnsider the fllwing issues in matters when a client is subject t a discvery request and ptentially relevant data exists with the clud prvider Pssessin, Custdy, and Cntrl In mst jurisdictins in the United States, a party s bligatin t prduce relevant infrmatin is limited t dcuments and data within its pssessin, custdy r cntrl. Hsting relevant data at a third-party, even a clud prvider, generally des nt bviate a party s bligatin t prduce infrmatin as it may have a legal right t access r btain the data. Hwever, nt all data hsted by a clud prvider may be in the cntrl f a client (e.g., disaster recvery systems, certain metadata created and maintained by the clud prvider t perate its envirnment). Distinguishing the data that is and is nt available t the client may be in the interest f the client and prvider. The bligatins f the clud service prvider as clud data handler with regard t the prductin f infrmatin in respnse t legal prcess is an issue left t each jurisdictin t reslve Relevant Clud Applicatins and Envirnment In certain litigatins and investigatins, the actual clud applicatin r envirnment culd itself be relevant t reslving the dispute in the litigatin r investigatin. In these circumstances, the applicatin and envirnment will likely be utside the cntrl f the client and require a subpena r ther discvery prcess n the prvider directly CLOUD SECURITY ALLIANCE 39

41 3.3.3 Searchability and E-Discvery Tls Because f the clud envirnment, a client may nt be able t apply r use e-discvery tls that it uses in its wn envirnment. Mrever, a client may nt have the ability r administrative rights t search r access all f the data hsted in the clud. Fr example, where a client culd access multiple emplyees accunts n its wn server at nce, it may nt have this ability with accunts hsted in the clud. As such, clients need t accunt fr the ptential additinal time, and expense, that this limited access will cause Preservatin Generally speaking, in the United States, a party is bligated t undertake reasnable steps t prevent the destructin r mdificatin f data r infrmatin in its pssessin, custdy, r cntrl that it knws, r reasnably shuld knw, is relevant t a pending r reasnably anticipated litigatin r gvernment investigatin. Depending n the clud service and deplyment mdel that a client is using, preservatin in the clud can be very similar t preservatin in ther IT infrastructures, r it can be significantly mre cmplex. In the Eurpean Unin, infrmatin preservatin is gverned under Directive 2006/24/EC f the Eurpean Parliament and f the Cuncil f 15 March Japan, Suth Krea, and Singapre have similar data prtectin initiatives. Within Suth America, Brazil and Argentina have the Azered Bill, and the Argentina Data Retentin Law 2004, Law N , 6 February 2004, respectively Csts and Strage Preservatin can require that large vlumes f data be retained fr extended perids. What are the ramificatins f this under the service level agreement ( SLA )? What happens if the preservatin requirements utlast the terms f the SLA? If the client preserves the data in place, wh pays fr the extended strage and at what cst? Des the client have the strage capacity under its SLA? Can the client effectively dwnlad the data in a frensically sund manner s it can preserve it ff-line r near-line? Scpe f Preservatin Absent gd cause r a specific need, a requesting party is nly entitled t data that is hsted in the clud that cntains relevant infrmatin, nt all the data in the clud r in the applicatin. Hwever, if the client des nt have the ability t preserve relevant infrmatin r data in a granular way, it may be required t ver-preserve in rder t effect reasnable preservatin, depending n the litigatin r investigatin Dynamic and Shared Strage The burden f preserving data in the clud may be relatively mdest if the client has space t hld it in place, the data is relatively static, and the peple with access are limited and knw t preserve it. Hwever, in a clud envirnment that prgrammatically mdifies r purges data, r ne where the data is shared with peple unaware f the need t preserve, preservatin can be mre difficult. After a client determines that such data is relevant and needs t be preserved, the client may need t wrk with the prvider t determine a reasnable way t preserve such data CLOUD SECURITY ALLIANCE 40

42 3.3.5 Cllectin Because f the ptential lack f administrative cntrl a client has ver its data in the clud, cllectin frm the clud can be mre difficult, mre time-cnsuming, and mre expensive than frm behind a client s firewall. In particular, a client may nt have the same level f visibility acrss its clud data, and it may have mre difficulty cmparing the data it has cllected with the data in the clud t determine that exprt was reasnably cmplete and accurate Access and Bandwidth In mst cases, a client s access t its data in the clud will be determined by its SLA. This may limit its ability t cllect large vlumes f data quickly and in a frensically sund manner (i.e., with all reasnably relevant metadata preserved). Clients and clud prviders are well served t cnsider this issue early and establish a prtcl (and a cst) fr extrardinary access in the case f litigatin and investigatins t allw fr cllectin. Absent these agreements, clients shuld cnsider the extra time and cst implicated by cllectin in the clud when making representatins t requesting parties and curts Functinality Related t access and bandwidth, but different. Clients right f access may prvide them access t a full range f data, but nt prvide them the degree f functinality that wuld best assist them in a given situatin. By way f example, a client may have access t three years f retail transactinal data, but may nly be able t dwnlad data tw weeks at a time due t functinality cnstraints. Mrever, a client may nt have full view int all the metadata that actually exists, but rather nly a mre limited degree f metadata Frensics Bit-by-bit imaging f a clud data surce is generally difficult r impssible. Fr bvius security reasns, prviders are reluctant t allw access t their hardware, particularly in a multi-tenant envirnment where a client culd gain access t ther clients data. Even in a private clud, frensics may be extremely difficult, and clients may need t ntify ppsing cunsel r the curts f these limitatins. Luckily, frensics is rarely warranted in clud cmputing, nt because it is clud cmputing, but because it is usually a structured data hierarchy r virtualizatin that des nt lend itself t frensic analysis Reasnable Integrity A client subject t a discvery request shuld undertake reasnable steps t validate that its cllectin frm its clud prvider is cmplete and accurate, especially where rdinary business prcedures are unavailable and litigatin-specific measures are being used t btain the infrmatin. This prcess is separate and apart frm verifying, that the data stred in the clud is accurate, authenticated, r admissible Nt Reasnably Accessible Because f differences in hw a client s data is stred and the client s access rights and privileges, nt all f a client s data in the clud may be equally accessible. The client (and the prvider) shuld analyze requests fr infrmatin and the pertinent data structure fr relevance, materiality, prprtinality and accessibility CLOUD SECURITY ALLIANCE 41

43 3.3.6 Direct Access Outside f the clud envirnment, a requesting party s direct access t a respnding party s IT envirnment is nt favred. In the clud envirnment, it is even less favred and may be impssible fr the same reasns as frensics. Imprtantly, a client may nt be able t prvide direct access because the hardware and facilities are utside its pssessin, custdy r cntrl, and a requesting party wuld need t subpena r negtiate directly with the prvider Native Prductin Clud service prviders ften stre data in highly prprietary systems and applicatins in the clud that clients d nt cntrl. Prductin f data in this native frmat may be useless t requesting parties, as they will nt be able t understand the infrmatin prduced. In these circumstances, it may be best fr all cncerned requesting party, prducing party, and prvider that the relevant infrmatin be exprted using standard reprting r exprting prtcls that exist within the clud envirnment Authenticatin Authenticatin in this cntext refers t frensic authenticatin f data that is admitted int evidence. This shuld nt be cnfused with user authenticatin, which is a cmpnent f Identity Management. String data in the clud des nt affect the analysis fr authenticatin f the data t determine if it shuld be admitted int evidence. The questin is whether the dcument is what it purprts t be. An is n mre r less authentic because it was stred behind a cmpany s firewall r was stred in the clud. The questin is whether it was stred with integrity and the curt can trust that it has nt been altered since it was sent r received Admissibility and Credibility Absent ther evidence, such as tampering r hacking, dcuments shuld nt be cnsidered mre r less admissible r credible merely because they were created r stred in the clud Cperatin between Prvider and Client in e-discvery It is in the best interests f bth prviders and clients t cnsider the cmplicatins caused by discvery at the beginning f their relatinship and t accunt fr it in their SLAs. Prviders may want t cnsider designing their clud fferings t include discvery services t attract clients ( Discvery by Design ). In any event, clients and prviders shuld cnsider including an agreement t reasnably cperate with each ther in the event f discvery requests against either Respnse t a Subpena r Search Warrant The clud service prvider is likely t receive, frm third parties, a request t prvide infrmatin, in the frm f a subpena, a warrant, r curt rder in which access t the client data is requested. The client may want t have the ability t fight the request fr access in rder t prtect the cnfidentiality r secrecy f the data sught. T this end, 2011 CLOUD SECURITY ALLIANCE 42

44 the clud services agreement shuld require the clud service prvider t ntify the cmpany that a subpena was received and give the cmpany time t fight the request fr access. The clud service prvider might be tempted t reply t the request by pening its facilities and prviding the requestrs with whatever infrmatin is identified in the access request. Befre ding s, the clud service prvider shuld ensure that the request is in gd rder, and uses the apprpriate legal methd. The clud service prvider shuld carefully analyze the request befre disclsing infrmatin in its custdy. Cmplex laws apply depending n the specific nature f the infrmatin, its lcatin, etc. Fr example, different rules apply fr requesting access t the cntent f an , depending n whether r nt the has been pened, and hw lng the has been stred. Different rules apply if the infrmatin requested is the cntent f the , r nly the transactinal data abut the (e.g., when sent, t whm, etc.) CLOUD SECURITY ALLIANCE 43

45 REFERENCES Internatinal Treaties and Agreements [1] OECD Guidelines n the Prtectin f Privacy and Transbrder Flws f Persnal Data (1980). [2] OECD Guidelines fr the Security f Infrmatin Systems and Netwrks (2002). [3] OECD Recmmendatin n Crss-brder Cperatin in the Enfrcement f Laws Prtecting Privacy. Publicatins [4] GILBERT, Francise Glbal Privacy & Security. Aspen Publishing / Wlters Kluwer (2 vlumes). [5] GILBERT, Francise Clud Service Prviders Can Be Bth Data Prcessrs and Data Cntrllers (BNA Privacy & Security Law Reprt 10 PVLR 266 (2011). Jurnal f Internet Law, Vlume 15, Number 2, page 3. [6] POWER, Michael E. AND TROPE, Rland L Sailing in Dangerus Waters: A Directr s Guide t Data Gvernance. American Bar Assciatin. [7] SMEDINGHOFF, Thmas Infrmatin Security Law: Emerging Standard fr Crprate Cmpliance (ITGP). Websites [8] Clud cmputing definitins and business mdels: (technical aspects, business mdels) [9] Clud Cmputing Incidents Database: (Recrds and mnitrs verifiable, ntewrthy events that affect clud cmputing prviders, such as utages, security issues, and breaches) 2011 CLOUD SECURITY ALLIANCE 44

46 DOMAIN 4 // COMPLIANCE AND AUDIT MANAGEMENT SECURITY GUIDANCE FOR CRITICAL AREAS OF Organizatins face new challenges as they migrate frm traditinal data centers t the clud. Delivering, measuring, and cmmunicating cmpliance with a multitude f regulatins acrss multiple jurisdictins is ne f the largest challenges. Custmers and prviders alike need t understand and appreciate the differences and implicatins n existing cmpliance and audit standards, prcesses, and practices. The distributed and virtualized nature f clud requires significant framewrk adjustment frm appraches based n definite and physical instantiatins f infrmatin and prcesses. Clud has the ptential t imprve transparency and assurance, thrugh its mre centralized and cnslidated management platfrms. Mrever, the utsurced slutins frm clud prviders reduce the scale-dependency f cmpliance. With prviders able t deliver first-day cmpliant slutins, new firms (fr-prfit and nn-prfit) wuld be able t enter markets and take actins that wuld have been cst-prhibitive in a pre-clud era. Gvernments and ther rganizatins previusly reluctant t utsurce IT peratins due t issues f security and cmpliance may be mre ready t adpt a clud mdel, where cmpliance can be partly addressed thrugh cntractual delegatin. In additin t prviders and custmers, regulatrs and auditrs are als adjusting t the new wrld f clud cmputing. Few existing regulatins were written t accunt fr virtualized envirnments r clud deplyments. A clud cnsumer can be challenged t shw auditrs that the rganizatin is in cmpliance. Understanding the interactin f clud cmputing and the regulatry envirnment is a key cmpnent f any clud strategy. Clud custmers must cnsider and understand the fllwing: Regulatry implicatins fr using a particular clud service r prviders, giving particular attentin t any crssbrder r multi-jurisdictinal issues when applicable Assignment f cmpliance respnsibilities between the prvider and custmer, including indirect prviders (i.e., the clud prvider f yur clud prvider) Prvider capabilities fr demnstrating cmpliance, including dcument generatin, evidence prductin, and prcess cmpliance, in a timely manner Relatinships between custmer, prviders and auditrs (bth the custmer's and prvider's) t ensure required (and apprpriately restricted) access and alignment with gvernance requirements Overview. This dmain will address the fllwing tpics: Cmpliance Audit 2011 CLOUD SECURITY ALLIANCE 45

47 4.1 Cmpliance Figure 1 GRC Value Ecsystem Crprate Gvernance: the balance f cntrl between stakehlders, directrs and managers f an rganizatin prviding cnsistent management, chesive applicatin f plicies, guidance and cntrls, and enabling effective decisin-making Enterprise Risk Management: methds and prcesses (framewrk) used by rganizatins t balance decisinmaking based n identifying particular events r circumstances relevant t the rganizatin's bjectives (risks and pprtunities), assessing them in terms f likelihd and magnitude f impact, determining a respnse strategy, and mnitring prgress t prtect and create value fr their stakehlders Cmpliance and Audit Assurance: awareness and adherence t crprate bligatins (e.g., crprate scial respnsibility, ethics, applicable laws, regulatins, cntracts, strategies and plicies) by assessing the state f cmpliance, assessing the risks and ptential csts f nn-cmpliance against the csts t achieve cmpliance, and hence priritize, fund, and initiate any crrective actins deemed necessary Infrmatin technlgy in the clud is increasingly subject t a plethra f plicies and regulatins. All stakehlders expect rganizatins t practively cmply with regulatry guidelines and requirements acrss multiple jurisdictins. IT gvernance is a necessity t deliver against these requirements and all rganizatins need a strategy t deliver. Gvernance includes the prcesses and plicies that enable the smth executin f rganizatinal bjectives within the cnstraints f the external envirnment. Gvernance requires cmpliance activities t ensure that peratins are fully aligned with thse prcesses and plicies. In this sense, cmpliance is fcused n aligning with external requirements (e.g., law, regulatin, industry standards) while gvernance is fcused n aligning with internal requirements (e.g., bard decisins, crprate plicy). Cmpliance can be defined as the awareness and adherence t bligatins (e.g., crprate scial respnsibility, applicable laws, ethical guidelines), including the assessment and priritizatin f crrective actins deemed necessary and apprpriate. In sme envirnments, particularly thse highly regulated, the transparency aspect can even be dminant with reprting requirements getting mre attentin than cmpliance itself. In the best circumstances, cmpliance is nt an inhibitr f rganizatinal effectiveness, but a cmplement t internally determined plicies CLOUD SECURITY ALLIANCE 46

48 Regulatins typically have strng implicatins fr infrmatin technlgy and its gvernance, particularly in terms f mnitring, management, prtectin, and disclsure). IT gvernance is a supprting element in verall crprate gvernance, enterprise risk management, cmpliance, and audit/assurance. Clud can be an enabling technlgy fr gvernance and cmpliance, centralizing cntrl and transparency thrugh its management platfrms, particularly fr internally management clud. By leveraging clud services, sub-scale rganizatins can achieve the same level f cmpliance as much larger and highly resurces entities. Security and assurance services are ne way third-parties can play a rle in cmpliance assessment and cmmunicatin. Any cmpliance apprach will need t include participatin acrss the rganizatin, including IT. The rle f external prviders needs t be carefully cnsidered, and respnsibility fr including them in gvernance, indirectly r directly, shuld be explicitly assigned within the custmer rganizatin. In additin, the fllwing represent a number f clud security standards that are in develpment within ISO/IEC and ITU-T: ISO/IEC 27017: Clud Cmputing Security and Privacy Management System-Security Cntrls ISO/IEC x: Multipart standard fr the infrmatin security f supplier relatinship management that is planned t include a part relevant t the clud supply chain ITU-T X.ccsec: Security guideline fr clud cmputing in telecmmunicatin area ITU-T X.srfcts: Security requirements and framewrk f clud-based telecmmunicatin service envirnment (X.srfcts) ITU-T X.sfcse: Security functinal requirements fr Sftware as a Service (SaaS) applicatin envirnment 4.2 Audit Prper rganizatinal gvernance naturally includes audit and assurance. Audit must be independently cnducted and shuld be rbustly designed t reflect best practice, apprpriate resurces, and tested prtcls and standards. Bth internal and external audit and cntrls have legitimate rles t play fr clud, fr bth the custmer and prvider. Greater transparency may be best during initial stages f clud intrductin, t increase stakehlder cmfrt levels. An audit is ne methd t prvide assurance that peratinal risk management activities are thrughly tested and reviewed. An audit plan shuld be adpted and supprted by the mst senir gverning elements f the rganizatin (e.g., the bard and management). Regular and independent audits f critical systems and cntrls, including the accmpanying audit trail and dcumentatin will supprt imprvements in efficiency and reliability. Many rganizatins use a maturity mdel (e.g., CMM, PTQM) as a framewrk fr analyzing prcess effectiveness. In sme cases, a mre statistical apprach t risk management is adpted (e.g., Basel and Slvency accrds fr financial services) and as the field matures mre specialized mdels fr risk can be adpted as apprpriate fr the functin r line f business CLOUD SECURITY ALLIANCE 47

49 Fr clud, these practices will need t be revised and enhanced. Just as with previus mdels f infrmatin technlgy, audit will need t take advantage f the ptential f clud, as well as increase scpe and scale t manage its nvel aspects. 4.3 Recmmendatins When engaging a prvider, invlve the apprpriate legal, prcurement, and cntracts teams within the custmer rganizatin. The standard terms f services may nt address cmpliance needs, and wuld need t be negtiated. Specialized cmpliance requirements fr highly regulated industries (e.g., finance, health care) shuld be cnsidered when using a clud service. Organizatins wh understand their current requirements shuld cnsider the impact f a distributed IT mdel, including the impact f clud prviders perating in diverse gegraphic lcatins and different legal jurisdictins. Determine hw existing cmpliance requirements will be impacted by the use f clud services, fr each wrklad (i.e., set f applicatins and data), in particular as they relate t infrmatin security. As with any utsurced slutin, rganizatins need t understand which f their clud partners are and shuld be prcessing regulated infrmatin. Examples f impacted plicies and prcedures include activity reprting, lgging, data retentin, incident respnse, cntrls testing, and privacy plicies. Understand the cntractual respnsibilities f each party. The baseline expectatins will vary by deplyment mdel with the custmer having mre cntrl and respnsibility in an IaaS mdel, and the prvider having the dminant rle fr SaaS slutins. Particularly imprtant is chained requirements and bligatins nt just the custmer t their direct clud prvider, but between the end custmer and the prvider s clud prvider. Cmpliance with laws and industry regulatin and its requirement (i.e. laws, technical, legal, cmpliance, risk, and security) is critical and must address during requirements identificatin stage. Any infrmatin prcessed, transmitted, stred, r viewed that is identified as Persnal Identifiable Infrmatin (PII) 22 r private infrmatin faces a plethra f cmpliance regulatin wrldwide that may vary cuntry r state. Since clud was designed t be gegraphically diverse and scalable, slutin data may be stred, prcessed, transmitted, r retrieved frm many lcatins r multiple data centers f CSP. Sme regulatry requirements specify cntrls that are difficult r impssible t achieve in certain clud service types (e.g., gegraphic requirements may be incnsistent with distribute strage). Custmers and prviders must agree hw t cllect, stre, and share cmpliance evidence (e.g., audit lgs, activity reprts, system cnfiguratins). Prefer auditrs that are "clud aware" that will be familiar with the assurance challenges (and advantages) f virtualizatin and clud. Request clud Prvider s SSAE 16 SOC2 r ISAE 3402 Type 2 reprt. These will prvide a recgnizable starting pint f reference fr auditrs and assessrs. Cntracts shuld prvide fr third-party review f SLA metrics and cmpliance (e.g., by a mutually-selected mediatr). 22 PII - Persnal Identifiable Infrmatin 2011 CLOUD SECURITY ALLIANCE 48

50 4.3 Requirements A right t audit clause gives custmers the ability t audit the clud prvider, which supprts traceability and transparency in the frequently evlving envirnments f clud cmputing and regulatin. Use a nrmative specificatin in the right t audit t ensure mutual understanding f expectatins. In time, this right shuld be supplanted by third-party certificatins (e.g., driven by ISO/IEC 27001/27017). A right t transparency clause with specified access rights can prvide custmers in highly regulated industries (including thse in which nn-cmpliance can be grunds fr criminal prsecutin) with required infrmatin. The agreement shuld distinguish between autmated/direct access t infrmatin (e.g., lgs, reprts) and 'pushed' infrmatin (e.g., system architectures, audit reprts). Prviders shuld review, update, and publish their infrmatin security dcuments and GRC prcesses regularly (r as required). These shuld include vulnerability analysis and related remediatin decisins and activities. Third-party auditrs shuld be mutually disclsed r selected in advance, jintly by prvider and custmer. All parties shuld agree t use a cmmn certificatin assurance framewrk (e.g., frm ISO, COBIT) fr IT gvernance and security cntrls CLOUD SECURITY ALLIANCE 49

51 DOMAIN 5 // INFORMATION MANAGEMENT AND DATA SECURITY SECURITY GUIDANCE FOR CRITICAL AREAS OF The primary gal f infrmatin security is t prtect the fundamental data that pwers ur systems and applicatins. As cmpanies transitin t clud cmputing, the traditinal methds f securing data are challenged by clud-based architectures. Elasticity, multi-tenancy, new physical and lgical architectures, and abstracted cntrls require new data security strategies. In many clud deplyments, users even transfer data t external r even public envirnments in ways that wuld have been unthinkable nly a few years ag. Managing infrmatin in the era f clud cmputing is a daunting challenge that affects all rganizatins; even thse that aren t seemingly actively engaged in clud-based prjects. It begins with managing internal data and clud migratins and extends t securing infrmatin in diffuse, crss-rganizatin applicatins and services. Infrmatin management and data security in the clud era demand bth new strategies and technical architectures. Frtunately nt nly d users have the tls and techniques needed, but the clud transitin even creates pprtunities t better secure data in ur traditinal infrastructure. The authrs recmmend using a Data Security Lifecycle (explred belw) fr evaluating and defining clud data security strategy. This shuld be layered with clear infrmatin gvernance plicies, and then enfrced by key technlgies such as encryptin and specialized mnitring tls. Overview. This dmain includes three sectins: Sectin 1 prvides backgrund material n clud infrmatin (strage) architectures. Sectin 2 includes best practices fr infrmatin management, including the Data Security Lifecycle. Sectin 3 details specific data security cntrls, and when t use them. 5.1 Clud Infrmatin Architectures Clud infrmatin architectures are as diverse as the clud architectures themselves. While this sectin can t pssibly cver all ptential permutatins, there are certain cnsistent architectures within mst clud services Infrastructure as a Service IaaS, fr public r private clud, generally includes the fllwing strage ptins: Raw strage. This includes the physical media where data is stred. May be mapped fr direct access in certain private clud cnfiguratins. Vlume strage. This includes vlumes attached t IaaS instances, typically as a virtual hard drive. Vlumes ften use data dispersin t supprt resiliency and security CLOUD SECURITY ALLIANCE 50

52 Object strage. Object strage is smetimes referred t as file strage. Rather than a virtual hard drive, bject strage is mre like a file share accessed via API s 23 r web interface. Cntent Delivery Netwrk. Cntent is stred in bject strage, which is then distributed t multiple gegraphically distributed ndes t imprve Internet cnsumptin speeds Platfrm as a Service PaaS bth prvides and relies n a very wide range f strage ptins. PaaS may prvide: Database as a Service. A multitenant database architecture that is directly cnsumable as a service. Users cnsume the database via APIs r direct SQL 24 calls, depending n the ffering. Each custmer s data is segregated and islated frm ther tenants. Databases may be relatinal, flat, r any ther cmmn structure. Hadp/MapReduce/Big Data as a Service. Big Data is data whse large scale, brad distributin, hetergeneity, and currency/timeliness require the use f new technical architectures and analytics. Hadp and ther Big Data applicatins may be ffered as a clud platfrm. Data is typically stred in Object Strage r anther distributed file system. Data typically needs t be clse t the prcessing envirnment, and may be mved temprally as needed fr prcessing. Applicatin strage. Applicatin strage includes any strage ptins built int a PaaS applicatin platfrm and cnsumable via API s that desn t fall int ther strage categries. PaaS may cnsume: Databases. Infrmatin and cntent may be directly stred in the database (as text r binary bjects) r as files referenced by the database. The database itself may be a cllectin f IaaS instances sharing cmmn back-end strage. Object/File Strage. Files r ther data are stred in bject strage, but nly accessed via the PaaS API. Vlume Strage. Data may be stred in IaaS vlumes attached t instances dedicated t prviding the PaaS service. Other. These are the mst cmmn strage mdels, but this is a dynamic area and ther ptins may be available Sftware as a Service As with PaaS, SaaS uses a very wide range f strage and cnsumptin mdels. SaaS strage is always accessed via a web-based user interface r client/server applicatin. If the strage is accessible via API then it s cnsidered PaaS. Many SaaS prviders als ffer these PaaS APIs. 23 API - Applicatin Prgram Interface 24 SQL - Structural Query Language is prgramming language designed fr managing data 2011 CLOUD SECURITY ALLIANCE 51

53 SaaS may prvide: Infrmatin Strage and Management. Data is entered int the system via the web interface and stred within the SaaS applicatin (usually a back-end database). Sme SaaS services ffer data set uplad ptins, r PaaS API s. Cntent/File Strage. File-based cntent is stred within the SaaS applicatin (e.g., reprts, image files, dcuments) and made accessible via the web-based user interface. SaaS may cnsume: Databases. Like PaaS, a large number f SaaS services rely n database back-ends, even fr file strage. Object/File Strage. Files r ther data are stred in bject strage, but nly accessed via the SaaS applicatin. Vlume Strage. Data may be stred in IaaS vlumes attached t instances dedicated t prviding the SaaS service. 5.2 Data (Infrmatin) Dispersin Data (Infrmatin) Dispersin is a technique that is cmmnly used t imprve data security, but withut the use f encryptin mechanisms. These srts f algrithms (IDA 25 fr shrt) are capable f prviding high availability and assurance fr data stred in the clud, by means f data fragmentatin, and are cmmn in many clud platfrms. In a fragmentatin scheme, a file f is split int n fragments; all f these are signed and distributed t n remte servers. The user then can recnstruct f by accessing m arbitrarily chsen fragments. The fragmentatin mechanism can als be used fr string lng-lived data in the clud with high assurance. When fragmentatin is used alng with encryptin, data security is enhanced: an adversary has t cmprmise m clud ndes in rder t retrieve m fragments f the file f, and then has t break the encryptin mechanism being used. 5.3 Infrmatin Management Befre we can discuss specific data security cntrls, we need a mdel t understand and manage ur infrmatin. Infrmatin management includes the prcesses and plicies fr bth understanding hw yur infrmatin is used, and gverning that usage. In the data security sectin, specific technical cntrls and recmmendatins are discussed t mnitr and enfrce this gvernance. 5.4 The Data Security Lifecycle Althugh Infrmatin Lifecycle Management is a fairly mature field, it desn t map well t the needs f security prfessinals. The Data Security Lifecycle is different frm Infrmatin Lifecycle Management, reflecting the different needs f the security audience. This is a summary f the lifecycle, and a cmplete versin is available at 25 IDA - Intrusin Detectin Algrithms 2011 CLOUD SECURITY ALLIANCE 52

54 The lifecycle includes six phases frm creatin t destructin. Althugh it is shwn as a linear prgressin, nce created, data can bunce between phases withut restrictin, and may nt pass thrugh all stages (fr example, nt all data is eventually destryed). 1. Create. Creatin is the generatin f new digital cntent, r the alteratin/updating/mdifying f existing cntent. 2. Stre. String is the act cmmitting the digital data t sme srt f strage repsitry and typically ccurs nearly simultaneusly with creatin. 3. Use. Data is viewed, prcessed, r therwise used in sme srt f activity, nt including mdificatin. 4. Share. Infrmatin is made accessible t thers, such as between users, t custmers, and t partners. 5. Archive. Data leaves active use and enters lng-term strage. Figure 1 Data Lifecycle 6. Destry. Data is permanently destryed using physical r digital means (e.g., cryptshredding) Lcatins and Access The lifecycle represents the phases infrmatin passes thrugh but desn t address its lcatin r hw it is accessed. Lcatins This can be illustrated by thinking f the lifecycle nt as a single, linear peratin, but as a series f smaller lifecycles running in different perating envirnments. At nearly any phase data can mve int, ut f, and between these envirnments. Due t all the ptential regulatry, cntractual, and ther jurisdictinal issues it is extremely imprtant t understand bth the lgical and physical lcatins f data. Access When users knw where the data lives and hw it mves, they need t knw wh is accessing it and hw. There are tw factrs here: 1. Wh accesses the data? Figure 2 Clud Access Devices 2011 CLOUD SECURITY ALLIANCE 53

55 2. Hw can they access it (device & channel)? Data tday is accessed using a variety f different devices. These devices have different security characteristics and may use different applicatins r clients Functins, Actrs, and Cntrls The next step identifies the functins that can be perfrmed with the data, by a given actr (persn r system) and a particular lcatin. Functins There are three things we can d with a given datum: Access. View/access the data, including creating, cpying, file transfers, disseminatin, and ther exchanges f infrmatin. Prcess. Perfrm a transactin n the data: update it; use it in a business prcessing transactin, etc. Stre. Hld the data (in a file, database, etc.). Figure 3 Functins vs. Cntrls The table belw shws which functins map t which phases f the lifecycle: Table 1 Infrmatin Lifecycle Phases An actr (persn, applicatin, r system/prcess, as ppsed t the access device) perfrms each functin in a lcatin. Cntrls A cntrl restricts a list f pssible actins dwn t allwed actins. The table belw shws ne way t list the pssibilities, which the user then maps t cntrls. Table 2 Pssible and Allwed Cntrls 2011 CLOUD SECURITY ALLIANCE 54

56 5.5 Infrmatin Gvernance Infrmatin gvernance includes the plicies and prcedures fr managing infrmatin usage. It includes the fllwing key features: Infrmatin Classificatin. High-level descriptins f imprtant infrmatin categries. Unlike with data classificatin the gal isn t t label every piece f data in the rganizatin, but rather t define high-level categries like regulated and trade secret t determine which security cntrls may apply. Infrmatin Management Plicies. Plicies t define what activities are allwed fr different infrmatin types. Lcatin and Jurisdictinal Plices. Where data may be gegraphically lcated, which als has imprtant legal and regulatry ramificatins. Authrizatins. Define which types f emplyees/users are allwed t access which types f infrmatin. Ownership. Wh is ultimately respnsible fr the infrmatin. Custdianship. Wh is respnsible fr managing the infrmatin, at the bequest f the wner. 5.6 Data Security Data security includes the specific cntrls and technlgies used t enfrce infrmatin gvernance. This has been brken ut int three sectins t cver detectin (and preventin) f data migrating t the clud, prtecting data in transit t the clud and between different prviders/envirnments, and prtecting data nce it s within the clud Detecting and Preventing Data Migratins t the Clud A cmmn challenge rganizatins face with the clud is managing data. Many rganizatins reprt individuals r business units mving ften sensitive data t clud services withut the apprval r even ntificatin f IT r security. Aside frm traditinal data security cntrls (like access cntrls r encryptin), there are tw ther steps t help manage unapprved data mving t clud services: 1. Mnitr fr large internal data migratins with Database Activity Mnitring (DAM) 26 and File Activity Mnitring (FAM) Mnitr fr data mving t the clud with URL filters and Data Lss Preventin. 26 DAM - Database Activity Mnitring 27 FAM - File Activity Mnitring 2011 CLOUD SECURITY ALLIANCE 55

57 Internal Data Migratins Befre data can mve t the clud it needs t be pulled frm its existing repsitry. Database Activity Mnitring can detect when an administratr r ther user pulls a large data set r replicates a database, which culd indicate a migratin. File Activity Mnitring prvides similar prtectin fr file repsitries, such as file shares. Mvement t the Clud A cmbinatin f URL filtering (web cntent security gateways) and Data Lss Preventin (DLP) can detect data mving frm the enterprise int the clud. URL filtering allws yu t mnitr (and prevent) users cnnecting t clud services. Since the administrative interfaces fr these services typically use different addresses than the cnsumptin side, the user can distinguish between smene accessing an administrative cnsle versus a user accessing an applicatin already hsted with the prvider. Lk fr a tl that ffers a clud services list and keeps it up t date, as ppsed t ne that requires creating a custm categry, and the user managing the destinatin addresses. Fr greater granularity, use Data Lss Preventin. DLP tls lk at the actual data/cntent being transmitted, nt just the destinatin. Thus the user can generate alerts (r blck) based n the classificatin f the data. Fr example, the user can allw crprate private data t g t an apprved clud service but blck the same cntent frm migrating t an unapprved service. The insertin pint f the DLP slutin can determine hw successfully data leakage can be detected. Fr example, availability f clud slutins t varius users (e.g., emplyees, vendrs, custmers) utside f the crprate netwrk envirnment avids r nullifies any DLP slutins if they are inserted at the crprate bundary Prtecting Data Mving T (And Within) the Clud In bth public and private clud deplyments, and thrughut the different service mdels, it s imprtant t prtect data in transit. This includes: Data mving frm traditinal infrastructure t clud prviders, including public/private, internal/external and ther permutatins. Data mving between clud prviders. Data mving between instances (r ther cmpnents) within a given clud. There are three ptins (r rder f preference): 1. Client/Applicatin Encryptin. Data is encrypted n the endpint r server befre being sent acrss the netwrk r is already stred in a suitable encrypted frmat. This includes lcal client (agent-based) encryptin (e.g., fr stred files) r encryptin integrated in applicatins CLOUD SECURITY ALLIANCE 56

58 2. Link/Netwrk Encryptin. Standard netwrk encryptin techniques including SSL, VPNs, and SSH. Can be hardware r sftware. End t end is preferable but may nt be viable in all architectures. 3. Prxy-Based Encryptin. Data is transmitted t a prxy appliance r server, which encrypts befre sending further n the netwrk. Often a preferred ptin fr integrating int legacy applicatins but is nt generally recmmended Prtecting Data in the Clud With such a wide range f ptins and technlgies available in clud cmputing, there is n way t cver all pssible security ptins. The fllwing are sme f the mre useful technlgies and best practices fr securing data within varius clud mdels Cntent Discvery Cntent discvery includes the tls and prcesses t identify sensitive infrmatin in strage. It allws the rganizatin t define plicies based n infrmatin type, structure, r classificatin and then scans stred data using advanced cntent analysis techniques t identify lcatins and plicy vilatins. Cntent discvery is nrmally a feature f Data Lss Preventin tls; fr databases, it is smetimes available in Database Activity Mnitring prducts. Scanning can be via accessing file shares r a lcal agent running n an perating system. The tl must be clud aware and capable f wrking within yur clud envirnment (e.g., able t scan bject strage). Cntent discvery may als be available as a managed service IaaS Encryptin Vlume Strage Encryptin Vlume encryptin prtects frm the fllwing risks: Prtects vlumes frm snapsht clning/expsure Prtects vlumes frm being explred by the clud prvider (and private clud admins) Prtects vlumes frm being expsed by physical lss f drives (mre fr cmpliance than a real-wrld security issue) IaaS vlumes can be encrypted using three methds: Instance-managed encryptin. The encryptin engine runs within the instance, and the key is stred in the vlume but prtected by a passphrase r keypair. Externally managed encryptin. The encryptin engine runs in the instance, but the keys are managed externally and issued t the instance n request. Prxy encryptin. In this mdel yu cnnect the vlume t a special instance r appliance/sftware, and then cnnect yur instance t the encryptin instance. The prxy handles all crypt peratins and may keep keys either nbard r external CLOUD SECURITY ALLIANCE 57

59 Object Strage Encryptin Object strage encryptin prtects frm many f the same risks as vlume strage. Since bject strage is mre ften expsed t public netwrks, it als allws the user t implement Virtual Private Strage. Like a VPN, a VPS 28 allws use f a public shared infrastructure while still prtecting data, since nly thse with the encryptin keys can read the data even if it is therwise expsed. File/Flder encryptin and Enterprise Digital Rights Management. Use standard file/flder encryptin tls r EDRM t encrypt the data befre placing in bject strage. Client/Applicatin encryptin. When bject strage is used as the back-end fr an applicatin (including mbile applicatins), encrypt the data using an encryptin engine embedded in the applicatin r client. Prxy encryptin. Data passes thrugh an encryptin prxy befre being sent t bject strage PaaS Encryptin Since PaaS is s diverse, the fllwing list may nt cver all ptential ptins: Client/applicatin encryptin. Data is encrypted in the PaaS applicatin r the client accessing the platfrm. Database encryptin. Data is encrypted in the database using encryptin built in and supprted by the database platfrm. Prxy encryptin. Data passes thrugh an encryptin prxy befre being sent t the platfrm. Other. Additinal ptins may include API s built int the platfrm, external encryptin services, and ther variatins SaaS Encryptin SaaS prviders may use any f the ptins previusly discussed. It is recmmended t use per-custmer keys when pssible t better enfrce multi-tenancy islatin. The fllwing ptins are fr SaaS cnsumers: Prvider-managed encryptin. Data is encrypted in the SaaS applicatin and generally managed by the prvider. Prxy encryptin. Data passes thrugh an encryptin prxy befre being sent t the SaaS applicatin. Encryptin peratins shuld use whatever encryptin methd is mst apprpriate, which may include shared keys r public/private keypairs and an extensive PKI/PKO 29 (Public Key Infrastructure/Operatins) structure. Please see Dmain 11 fr mre infrmatin n encryptin and key management. 28 VPS - Virtual Private Strage 29 PKI/PKO - Public Key Infrastructure/Operatins 2011 CLOUD SECURITY ALLIANCE 58

60 5.6.4 Data Lss Preventin Data Lss Preventin (DLP) is defined as: Prducts that, based n central plicies, identify, mnitr, and prtect data at rest, in mtin, and in use, thrugh deep cntent analysis. DLP can prvide ptins fr hw data fund vilatin f plicy is t be handled. Data can be blcked (stpping a wrkflw) r allwed t prceed after remediatin by encryptin using methds such as DRM, ZIP, r OpenPGP. DLP is typically used fr cntent discvery and t mnitr data in mtin using the fllwing ptins: Dedicated appliance/server. Standard hardware placed at a netwrk chkepint between the clud envirnment and the rest f the netwrk/internet r within different clud segments. Virtual appliance Endpint agent Hypervisr-agent. The DLP agent is embedded r accessed at the hypervisr level, as ppsed t running in the instance. DLP SaaS. DLP is integrated int a clud service (e.g., hsted ) r ffered as a standalne service (typically cntent discvery) Database and File Activity Mnitring Database Activity Mnitring (DAM) is defined as: Database Activity Mnitrs capture and recrd, at a minimum, all Structured Query Language (SQL) activity in real time r near real time, including database administratr activity, acrss multiple database platfrms; and can generate alerts n plicy vilatins. DAM supprts near real time mnitring f database activity and alerts based n plicy vilatins, such as SQL injectin attacks r an administratr replicating the database withut apprval. DAM tls fr clud envirnments are typically agent-based cnnecting t a central cllectin server (which is typically virtualized). It is used with dedicated database instances fr a single custmer, althugh in the future may be available fr PaaS. File Activity Mnitring (FAM) is defined as: Prducts that mnitr and recrd all activity within designated file repsitries at the user level, and generate alerts n plicy vilatins. FAM fr clud requires use f an endpint agent r placing a physical appliance between the clud strage and the clud cnsumers CLOUD SECURITY ALLIANCE 59

61 5.6.6 Applicatin Security A large percentage f data expsures are the result f attacks at the applicatin layer, particularly fr web applicatins. Please see Dmain 10 fr mre infrmatin n applicatin security Privacy Preserving Strage Almst all clud-based strage systems require sme authenticatin f participants (clud user and/r CSP) t establish trust relatins, either fr nly ne endpint f cmmunicatin r fr bth. Althugh cryptgraphic certificates can ffer sufficient security fr many f these purpses, they d nt typically cater t privacy because they are bund t the identity f a real persn (clud user). Any usage f such a certificate expses the identity f the hlder t the party requesting authenticatin. There are many scenaris (e.g., strage f Electrnic Health Recrds) where the use f such certificates unnecessarily reveals the identity f their hlder. Over the past years, a number f technlgies have been develped t build systems in a way that they can be trusted, like nrmal cryptgraphic certificates, while at the same time prtecting the privacy f their hlder (i.e., hiding the real hlder s identity). Such attribute-based credentials are issued just like rdinary cryptgraphic credentials (e.g., X.509 credentials) using a digital (secret) signature key. Hwever, attribute-based credentials (ABCs) allw their hlder t transfrm them int a new credential that cntains nly a subset f the attributes cntained in the riginal credential. Still, these transfrmed credentials can be verified just like rdinary cryptgraphic credentials (using the public verificatin key f the issuer) and ffer the same strng security Digital Rights Management (DRM) At its cre, Digital Rights Management encrypts cntent, and then applies a series f rights. Rights can be as simple as preventing cpying, r as cmplex as specifying grup r user-based restrictins n activities like cutting and pasting, ing, changing the cntent, etc. Any applicatin r system that wrks with DRM prtected data must be able t interpret and implement the rights, which typically als means integrating with the key management system. There are tw brad categries f Digital Rights Management: Cnsumer DRM is used t prtect bradly distributed cntent like audi, vide, and electrnic bks destined fr a mass audience. There are a variety f different technlgies and standards, and the emphasis is n neway distributin. Enterprise DRM is used t prtect the cntent f an rganizatin internally and with business partners. The emphasis is n mre cmplex rights, plicies, and integratin within business envirnments and particularly with the crprate Directry Service. Enterprise DRM can secure cntent stred in the clud well but requires deep infrastructure integratin. It s mst useful fr dcument based cntent management and distributin. Cnsumer DRM ffers gd prtectin fr distributing cntent t custmers but des nt have a gd track recrd with mst technlgies being cracked at sme pint CLOUD SECURITY ALLIANCE 60

62 5.7 Recmmendatins Understand the clud strage architecture in use, which will help determine security risk and ptential cntrls. Chse strage with data dispersin when available. Use the Data Security Lifecycle t identify security expsures and determine the mst apprpriate cntrls. Mnitr key internal databases and file repsitries with DAM and FAM t identify large data migratins, which culd indicate data migrating t the clud. Mnitr emplyee Internet access with URL filtering and/r DLP tls t identify sensitive data mving t the clud. Select tls that include predefined categries fr clud services. Cnsider using filtering t blck unapprved activity. Encrypt all sensitive data mving t r within the clud at the netwrk layer, r at ndes befre netwrk transmissin. This includes all service and deplyment mdels. When using any data encryptin, pay particular attentin t key management (see Dmain 11). Use cntent discvery t scan clud strage and identify expsed sensitive data. Encrypt sensitive vlumes in IaaS t limit expsure due t snapshts r unapprved administratr access. The specific technique will vary depending n peratinal needs. Encrypt sensitive data in bject strage, usually with file/flder r client/agent encryptin. Encrypt sensitive data in PaaS applicatins and strage. Applicatin-level encryptin is ften the preferred ptin, especially since few clud databases supprt native encryptin. When using applicatin encryptin, keys shuld be stred external t the applicatin whenever pssible. If encryptin is needed fr SaaS, try t identify a prvider that ffers native encryptin. Use prxy encryptin if that isn t available and /r trust levels must be assured. Use DLP t identify sensitive data leaking frm clud deplyments. It is typically nly available fr IaaS, and may nt be viable fr all public clud prviders. Mnitr sensitive databases with DAM and generate alerts n security plicy vilatins. Use a clud-aware tl. Cnsider privacy preserving strage when ffering infrastructure r applicatins where nrmal access culd reveal sensitive user infrmatin. Remember that mst large data security breaches are the result f pr applicatin security. Clud prviders shuld nt nly fllw these practices, but expse data security tls and ptins t their custmers CLOUD SECURITY ALLIANCE 61

63 Remval f data frm a clud vendr either due t expiry f cntract r any ther reasn shuld be cvered in detail while setting up the SLA. This shuld cver deletin f user accunts, migratin r deletin f data frm primary / redundant strage, transfer f keys, etc. 5.8 Requirements Use the Data Security Lifecycle t identify security expsures and determine the mst apprpriate cntrls. Due t all the ptential regulatry, cntractual, and ther jurisdictinal issues it is extremely imprtant t understand bth the lgical and physical lcatins f data. Mnitr emplyee Internet access with URL filtering and/r DLP tls t identify sensitive data mving t the clud. Encrypt all sensitive data mving t r within the clud at the netwrk layer, r at ndes befre netwrk transmissin. Encrypt sensitive vlumes in IaaS t limit expsure due t snapshts r unapprved administratr access. Encrypt sensitive data in PaaS applicatins and strage CLOUD SECURITY ALLIANCE 62

64 REFERENCES [1] RABIN, M. O Efficient Dispersal f Infrmatin fr Security, Lad Balancing, and Fault Tlerance. J. ACM, 36(2), [2] SECUROSIS The Data Security Lifecycle. [3] SECUROSIS Understanding and Selecting a Data Lss Preventin Slutin. [4] SECUROSIS Understanding and Selecting a Database Activity Mnitring slutin. [5] CHAUM, D. L. Feb Untraceable Electrnic Mail, Return Addresses, and Digital Pseudnyms. Cmmunicatins f the ACM, 24 (2), CLOUD SECURITY ALLIANCE 63

65 DOMAIN 6 // INTEROPERABILITY AND PORTABILITY The advent f clud cmputing ffers unprecedented scalability t an rganizatin s IT prcessing and administrative capability unlike thse available in traditinal in-huse infrastructures. Almst instantaneusly, additinal capacity can be added, mved, r remved in respnse t dynamically changing prcessing needs. A new applicatin supprt system can be initiated t meet increased demand in a matter f hurs rather than weeks. Shuld demand fall back, the additinal capacity can be shut dwn just as quickly with n surplus hardware nw sitting idled. Gaining the benefits f this mre elastic envirnment requires bth interperability and prtability t be the design gals f any cludimplemented system, frm IaaS thrugh t SaaS. At ne end f the scale, Interperability and Prtability allws yu t scale a service acrss multiple disparate prviders n a glbal scale and have that system perate and appear as ne system. At the ther end, Interperability and Prtability allws the easy mvement f data and applicatins frm ne platfrm t anther, r frm ne service prvider t anther. Prtability and interperability are nt cnsideratins unique t clud envirnments and their related security aspects are nt new cncepts brught abut by clud cmputing. Hwever, the pen and ften shared prcessing envirnments that exist within the clud bring a need fr even greater precautins than are required fr traditinal prcessing mdels. Multi-tenancy means data and applicatins reside with data and applicatins f ther cmpanies and that access t cnfidential data (intended r unintended) is pssible thrugh shared platfrms, shared strage, and shared netwrks. This sectin defines the critical cnsideratin which shuld be addressed when designing fr prtability and interperability. Overview. The fllwing sectins define Interperability and Prtability in terms f: An intrductin t Interperability Recmmendatins t ensure Interperability An intrductin t Prtability Recmmendatins fr Prtability 6.1 An Intrductin t Interperability Interperability is the requirement fr the cmpnents f a clud ec-system t wrk tgether t achieve their intended result. In a clud cmputing ec-system the cmpnents may well cme frm different surces, bth clud and traditinal, public and private clud implementatins (knwn as hybrid-clud). Interperability mandates that thse 2011 CLOUD SECURITY ALLIANCE 64

66 cmpnents shuld be replaceable by new r different cmpnents frm different prviders and cntinue t wrk, as shuld the exchange f data between systems. Businesses, ver time, will make decisins that lead t the desire t change prviders. Reasns fr this desired change include: An unacceptable increase in cst at cntract renewal time The ability t get the same service at a cheaper price A prvider ceases business peratins A prvider suddenly clses ne r mre services being used withut acceptable migratin plans Unacceptable decrease in service quality, such as a failure t meet key perfrmance requirements r achieve service level agreements (SLA s) 30 A business dispute between clud custmer and prvider A lack f interperability (and als prtability) can lead t being lcked t a particular clud service prvider. The degree t which interperability can be achieved r maintained when cnsidering a clud prject ften will depend n the degree t which a clud prvider uses pen, r published, architectures and standard prtcls and standard API s 31. Thugh many vendrs f pen and standards based clud prvisin prvide prpriety hks and extensins (e.g. Eucalyptus) and enhancements that can impede bth interperability and prtability. 6.2 An Intrductin t Prtability Prtability defines the ease f ability t which applicatin cmpnents are mved and reused elsewhere regardless f prvider, platfrm, OS, infrastructure, lcatin, strage, the frmat f data, r API s. Prtability and interperability must be cnsidered whether the clud migratin is t public, private, r hybrid clud deplyment slutins. They are imprtant elements t cnsider fr service mdel selectin regardless f whether a migratin strategy is t Sftware as a Service (SaaS), Platfrm as a Service (PaaS), r Infrastructure as a Service (IaaS). Prtability is a key aspect t cnsider when selecting clud prviders since it can bth help prevent vendr lck-in and deliver business benefits by allwing identical clud deplyments t ccur in different clud prvider slutins, either fr the purpses f disaster recvery r fr the glbal deplyment f a distributed single slutin. Achieving prtability fr a clud service is generally reliant n the tw services perating in the same architectural ctant f the Clud Cube, as defined in Dmain One. Where services perate in different ctants, then prting a service usually means migrating the service back in-huse befre re-utsurcing it t an alternative clud service. 30 SLA - Service Level Agreement 31 API - Applicatin Prgram Interface 2011 CLOUD SECURITY ALLIANCE 65

67 Failure t apprpriately address prtability and interperability in a clud migratin may result in failure t achieve the desired benefits f mving t the clud and can result in cstly prblems r prject delays due t factrs that shuld be avided such as: Applicatin, vendr, r prvider lck-in chice f a particular clud slutin may restrict the ability t mve t anther clud ffering r t anther vendr Prcessing incmpatibility and cnflicts causing disruptin f service prvider, platfrm, r applicatin differences may expse incmpatibilities that cause applicatins t malfunctin within a different clud infrastructure Unexpected applicatin re-engineering r business prcess change mving t a new clud prvider can intrduce a need t rewrk hw a prcess functins r require cding changes t retain riginal behavirs Cstly data migratin r data cnversin lack f interperable and prtable frmats may lead t unplanned data changes when mving t a new prvider Retraining r retling new applicatin r management sftware Lss f data r applicatin security different security plicy r cntrl, key management r data prtectin between prviders may pen undiscvered security gaps when mving t a new prvider r platfrm Mving services t the clud is a frm f utsurcing; the glden rule f utsurcing is understand up-frnt and plan fr hw t exit the cntract. Prtability (and t an extent interperability) shuld therefre be a key criterin f any rganizatins strategy t mve int clud services, allwing fr a viable exit strategy t be develped. 6.3 Recmmendatins Interperability Recmmendatins Hardware Physical Cmputer Hardware The hardware will inevitably vary r change ver time and frm prvider t prvider leaving unavidable interperability gaps if direct hardware access is required. Whenever pssible, use virtualizatin t remve many hardware level cncerns, remembering that virtualizatin desn t necessarily remve all hardware cncerns, especially n current systems. If hardware must be directly addressed, it is imprtant t ensure that the same r better physical and administrative security cntrls exist when mving frm ne prvider t anther. Physical Netwrk Devices The netwrk devices including security devices will be different frm service prviders t service prviders alng with its API and cnfiguratin prcess. T maintain interperability the Netwrk physical hardware and netwrk & security abstractin shuld be in virtual dmain. As far as pssible API s shuld have the same functinally CLOUD SECURITY ALLIANCE 66

68 Virtualizatin While virtualizatin can help t remve cncerns abut physical hardware, distinct differences exist between cmmn hypervisrs (such as ZEN, VMware and thers). Using pen virtualizatin frmats such as OVF t help ensure interperability. Dcument and understand which specific virtualizatin hks are used n matter the frmat. It still may nt wrk n anther hypervisr. Framewrks Different platfrm prviders ffer different clud applicatin framewrks and differences d exist between them that affect interperability. Investigate the API s t determine where differences lie and plan fr any changes necessary that may be required t applicatin prcessing when mving t a new prvider. Use pen and published API s t ensure the bradest supprt fr interperability between cmpnents and t facilitate migrating applicatins and data shuld changing a service prvider becme necessary. Applicatins in the clud ften interperate ver the Internet and utages can be anticipated t ccur. Determine hw failure in ne cmpnent (r a slw respnse) will impact thers and avid stateful dependencies that may risk system data integrity when a remte cmpnent fails. Strage Strage requirements will vary fr different types f data. Structured data will mst ften require a database system, r require applicatin specific frmats. Unstructured data will typically fllw any f a number f cmmn applicatin frmats used by Wrd Prcessrs, Spreadsheets and Presentatin Managers. Here the cncern shuld be t mve data stred with ne service t anther seamlessly. Stre unstructured data in an established prtable frmat. Assess the need fr encryptin fr the data in transit. Check fr cmpatible database systems and assess cnversin requirements if needed. Security Data and applicatins in the clud reside n systems the user desn t wn and likely has nly limited cntrl ver. A number f imprtant items t cnsider fr interperable security include: Use SAML r WS-Security fr authenticatin s the cntrls can be interperable with ther standards-based systems. See dmain 12 fr mre detail. Encrypting data befre it is placed int the clud will ensure that it cannt be accessed inapprpriately within clud envirnments. See dmain 11 fr mre detail n encryptin CLOUD SECURITY ALLIANCE 67

69 When encryptin keys are in use, investigate hw and where keys are stred t ensure access t existing encrypted data is retained. See dmain 11 fr mre detail n key management. Understand yur respnsibilities and liabilities shuld a cmprmise ccur due t unanticipated gaps in prtectin methds ffered by yur service prvider. Lg file infrmatin shuld be handled with the same level f security as all ther data mving t the clud. Ensure that lg files are interperable t ensure cntinuity f lg analysis pre-and pst mve as well as cmpatibility with whatever lg management system is in use. When cmpleting a mve ensure that all data, lgs, and ther infrmatin is deleted frm the riginal system Prtability Recmmendatins There are a number f issues standing in the path f mving t the clud. Prtability cnsideratins and recmmendatins that impact mving t the clud include; Service Level. SLA s will differ acrss prviders, and there is a need t understand hw this may affect yur ability t change prviders. Different architectures. Systems in the clud may reside n disparate platfrm architectures. It is imprtant t be aware f hw these will limit prtability by understanding service and platfrm dependencies, which may include API s, hypervisrs, applicatin lgic, and ther restrictins. Security integratin. Clud systems intrduce unique prtability cncerns fr maintaining security, including: Authenticatin and identity mechanisms fr user r prcess access t systems nw must perate acrss all cmpnents f a clud system. Using pen standards fr Identity such as SAML will help t ensure prtability. Develping internal IAM system t supprt SAML assertins and internal system t accept SAML will aid future prtability f system t the clud. Encryptin keys shuld be escrwed lcally, and when pssible maintained lcally Metadata is an aspect f digital infrmatin that is ften and easily verlked as (typically) metadata is nt directly visible when wrking with files and dcuments. Metadata becmes an imprtant cnsideratin in the clud, because metadata mves with the dcument. When mving files and their metadata t new clud envirnments ensure cpies f file metadata are securely remved t prevent this infrmatin frm remaining behind and pening a pssible pprtunity fr cmprmise Recmmendatins fr Different Clud Mdels There are a number f generic risks and recmmendatins that are cmmn t all clud mdels. When substituting clud prviders it is nrmal t expect resistance frm the legacy clud prvider. This must be planned fr in the cntractual prcess as utlined in Dmain 3, in yur Business Cntinuity Prgram as utlined in Dmain 7, and as a part f yur verall gvernance in Dmain CLOUD SECURITY ALLIANCE 68

70 Understand the size f data sets hsted at a clud prvider. The sheer size f data may cause an interruptin f service during a transitin, r a lnger transitin perid than anticipated. Many custmers have fund that using a curier t ship hard drives is faster than electrnic transmissin fr large data sets. Dcument the security architecture and cnfiguratin f individual cmpnent security cntrls s they can be used t supprt internal audits, as well as t facilitate migratin t new prviders and aid the validatin f the new envirnment. Infrastructure as a Service (IaaS) Where the respnsibility f the clud prvider is t prvide basic cmputing utilities such as strage, cmputing pwer, etc., the clud custmer is respnsible fr a majrity f applicatin design tasks related t interperability. The clud prvider shuld prvide standardized hardware and cmputing resurces that can interact with varius disparate systems with minimal effrts. The clud prvider shuld strictly adhere t industry standards t maintain interperability. The prvider shuld be able t supprt cmplex scenaris such as clud brkerage, clud bursting, hybrid cluds, multi- clud federatin, etc. Understand hw virtual machine images can be captured and prted t new clud prviders and wh may use different virtualizatin technlgies. Example: Distributed Management Task Frce (DMTF) Open Virtualizatin frmat (OVF). Identify and eliminate (r at least dcument) any prvider-specific extensins t the virtual machine envirnment. Understand what practices are in place t make sure apprpriate de-prvisining f VM images ccurs after an applicatin is prted frm the clud prvider. Understand the practices used fr decmmissining f disks and strage devices. Understand hardware/platfrm based dependencies that need t be identified befre migratin f the applicatin/data. Ask fr access t system lgs, traces, and access and billing recrds frm the legacy clud prvider. Identify ptins t resume r extend service with the legacy clud prvider in part r in whle if new service prves t be inferir. Determine if there are any management-level functins, interfaces, r API s being used that are incmpatible with r unimplemented by the new prvider. Understand csts invlved fr mving data t and frm a clud prvider Determine what means are supprted fr mving data as efficiently t the clud as pssible thrugh using standard capabilities such as data cmpressin. Understand what security is prvided and wh maintains access t encryptin keys CLOUD SECURITY ALLIANCE 69

71 Platfrm as a Service (PaaS) The clud prvider is respnsible t prvide a platfrm n which the cnsumers can build their systems. They prvide with a runtime envirnment and an integrated applicatin stack. It allws develpers t quickly develp and deply custm applicatins n the ffered platfrms withut the need t build the infrastructure. The clud prvider prvides the entire infrastructure and its maintenance t its cnsumers. When pssible, use platfrm cmpnents with a standard syntax, pen API s, and pen standards, e.g. Open Clud Cmputing Interface (OCCI) 32 Understand what tls are available fr secure data transfer, backup, and restre. Understand and dcument applicatin cmpnents and mdules specific t the PaaS prvider and develp applicatin architecture with layers f abstractin t minimize direct access t prprietary mdules. Understand hw base services like mnitring, lgging, and auditing wuld transfer ver t a new vendr. Understand what prtectins are prvided fr data placed int the clud and data generated and maintained in the clud. Understand cntrl functins prvided by the legacy clud prvider and hw they wuld translate t the new prvider. When migrating t a new platfrm, understand the impacts n perfrmance and availability f the applicatin and hw these impacts will be measured. Understand hw testing will be cmpleted prir t and after migratin t verify that the services r applicatins are perating crrectly. Ensure that bth prvider and user respnsibilities fr testing are well knwn and dcumented. Sftware as a Service (SaaS) The clud prvider prvides applicatin capabilities ver the clud, and the client just manages his/her peratins and the infrmatin flwing in and ut f the system. The client needs a brwser, and majrity f the administrative at all the levels rests with the prvider. Perfrm regular data extractins and backups t a frmat that is usable withut the SaaS prvider. Understand whether metadata can be preserved and migrated. If needed use data escrw services. Understand that any custm tls will have t be redevelped, r the new vendr must prvide thse tls, r cmmit t prt (and supprt) these tls. Review and audit t ensure the cnsistency f cntrl effectiveness acrss ld and new prviders. 32 OCCI - Open Clud Cmputing Interface 2011 CLOUD SECURITY ALLIANCE 70

72 Ensure backups and ther cpies f lgs, access recrds, and any ther pertinent infrmatin which may be required fr legal and cmpliance reasns can be migrated. Understand the management, mnitring, and reprting interfaces and their integratin between envirnments. Test and evaluate all applicatins befre migratin, and dual run if feasible prir t cut-ver. Private Clud Private clud is when the cnsumer runs a clud envirnment / service within their enterprise r uses private clud ffering frm the clud prviders (typically extending the internal netwrk int a service prviders hsting centre). Ensure interperability exists between cmmn hypervisrs such as KVM, VMware, Xen. Ensure standard API s are used fr management functins such as users and their privilege management, VM image management, Virtual Machine management, Virtual Netwrk management, Service management, Strage management, Infrastructure management, Infrmatin Management, etc. Public Clud Interperability in public clud means expsing mst cmmn clud interfaces. They may be vendr specific r pen specificatins and interfaces such as OCCI, libclud, etc. Ensure that the clud prviders expse cmmn and/r pen interfaces t access all clud functins in their service ffering. Hybrid Clud In this scenari the cnsumer s lcal private infrastructure shuld have the capability t wrk with external clud prviders. A cmmn scenari is clud bursting, where an enterprise shares the lad with external clud prviders t meet peak demands. Ensure that the clud prviders expse cmmn and/r pen interfaces t access all clud functins in their service ffering. Ensure the ability t federate with different clud prviders t enable higher levels f scalability CLOUD SECURITY ALLIANCE 71

73 REFERENCES [1] [2] [3] Windws%20SSO%20v1%200--Chappell.pdf [4] [5] [6] [7] [8] [9] [10] CLOUD SECURITY ALLIANCE 72

74 SECTION III // OPERATING IN THE CLOUD 2011 CLOUD SECURITY ALLIANCE 73

75 DOMAIN 7 // TRADITIONAL SECURITY, BUSINESS CONTINUITY, & DISASTER RECOVERY With the emergence f clud cmputing as a preferred technlgy fr utsurcing IT peratins, the security issues inherent in the hsting mdel have assumed greater significance and criticality. Inherent in the cncept f clud cmputing are the risks assciated with entrusting cnfidential and sensitive data t third parties r pure-play clud service prviders (CSP) 33. The evlutin f clud services has enabled business entities t d mre with less: fewer resurces and better perating efficiency. This has many tangible benefits fr business, yet there are inherent security risks that must be evaluated, addressed, and reslved befre businesses will have cnfidence in securely utsurcing their IT requirements t clud service prviders. One purpse f this dmain is t assist clud service users t share a cmmn understanding f traditinal security (physical security) with clud service. Traditinal security can be defined as the measures taken t ensure the safety and material existence f data and persnnel against This sectin maps t Clud Cntrl Matrix Dmains IS-01 and IS-02 as well as ISO/IEC Clause 9. theft, espinage, sabtage, r harm. In the cntext f clud infrmatin security, this is abut infrmatin, prducts, and peple. Prper infrmatin security deplys many different layers t achieve its gal. This is referred t as "layered security r defense in depth. When implementing security measures, managers shuld acknwledge that n measure is ne hundred percent secure. Infrmatin security uses the depth f its layers t achieve a cmbined level f security. A weakness in any ne f these layers can cause security t break. Physical prtectin is the initial step in a layered apprach t clud infrmatin security. If it is nnexistent, implemented incrrectly, weak, exercised incnsistently, treated as a prject (fire-n-frget), r prperly reviewed and maintained, the best lgical security measures will nt make up fr the physical security weakness, and security verall can fail. An effective traditinal security prgram flws frm a well-develped series f risk assessments, vulnerability analysis, BCP/DR plicies, prcesses, and prcedures that are reviewed and tested n a regular basis. Well-develped physical security prgrams will result in physical security that is scalable with the business, repeatable acrss the rganizatin, measurable, sustainable, defensible, cntinually imprving, and cst-effective n an nging basis. Overview: Sme f the security risks assciated with clud cmputing are unique, and it is in this cntext the business cntinuity, disaster recvery, and traditinal security envirnments f a clud service prvider need t be assessed thrughly (e.g., using standard industry guidelines such as TOGAF 34, SABSA 35, ITIL 36, COSO 37, r COBIT 38 ). This dmain addresses: 33 CSP - Clud Service Prvider 34 TOGAF - The Open Grup Architecture Framewrk 35 SABSA - Sherwd Applied Business Security Architecture 2011 CLOUD SECURITY ALLIANCE 74

76 Establishing a Physical Security Functin Human Resurces Physical Security Business Cntinuity Disaster Recvery This sectin maps t Clud Cntrl Matrix Dmains FS-01, FS-02, FS-03, and FS-04 as well as ISO/IEC Clause Establishing a Traditinal Security Functin Outdated security fr IT equipment, netwrk technlgy, and telecmmunicatins is ften verlked in many rganizatins. This has resulted in many rganizatins installing cmputer equipment, netwrks, and gateways in buildings that did nt have prper physical facilities designed t secure the assets r maintain availability. T establish prper physical security fr IT equipment, netwrk technlgy, and telecmmunicatins assets in a clud envirnment, it is imprtant that respnsibilities be assigned t persnnel wh are apprpriately placed in a clud prvider s rganizatin. An individual in a management psitin within a clud prvider is respnsible fr managing planning, implementatin, and maintenance f relevant plans and prcedures. Persnnel respnsible fr physical security need t be trained and have their perfrmance evaluated. In establishing a physical security functin within a clud envirnment, the fllwing must be cnsidered: The security needs fr the equipment and services being prtected The human resurces that are in place fr physical security Hw legacy physical security effrts have been managed and staffed prir t transitin t clud Financial resurces available fr these effrts Physical security can be as simple as adding a lcked dr r as elabrate as implementing multiple layers f barriers and armed security guards. Prper physical security uses the cncept f layered defense in apprpriate cmbinatins fr managing risk by deterring and delaying physical security threats. Physical threats t infrastructure, persnnel, and systems are nt limited t intrusins. T mitigate these risks, cmbinatins f bth active and passive defense are deplyed, t include having measures such as: Obstacles t deter and delay events, incidents, and attacks Detectin systems t mnitr security and envirnmental cnditins Security respnse designed t repel, apprehend, r discurage attackers Physical security nrmally takes ne f several frms in design and implementatin: Envirnmental design 36 ITIL - Infrmatin Technlgy Infrastructure Library 37 COSO - Cmmittee f Spnsring Organizatins 38 COBIT - Cntrl Objectives fr Infrmatin and Related Technlgy 2011 CLOUD SECURITY ALLIANCE 75

77 Mechanical, electrnic, and prcedural cntrls Detectin, respnse, and recvery prcedures Persnnel identificatin, authenticatin, authrizatin, and access cntrl Plicies and prcedures, including training f staff Evaluatin f Traditinal Physical Security When evaluating the traditinal security f a CSP, cnsumers cnsider the aspects f the infrastructure as a service/physical presence f the fundatinal data center prvider. These include the physical lcatin f the facility and the dcumentatin f critical risk and recvery factrs Physical Lcatin f the CSP Facility Cnsumers shuld cnduct a critical evaluatin f the data center s physical lcatin. If they are dependent n a clud supply chain, it is imprtant t understand the clud infrastructure n which they depend. The fllwing are suggestins in evaluating the physical lcatin f the facility: Check if the lcatin f the facility falls under any active seismic zne and the risks f seismic activity The facility shuld nt be lcated in a gegraphic regin which is prne t: flding, landslides, r ther natural disasters The facility shuld nt be in an area with high crime, plitical r scial unrest Check the accessibility f the facility s lcatin (and frequency f inaccessibility) Dcumentatin Review The dcumentatin supprting recvery peratins is critical in evaluating the readiness f the hsting cmpany t recver frm a catastrphic event. The fllwing sets f dcumentatin shuld be inspected prir t engagement f a physical data center prvider: Risk Analysis Risk Assessments Vulnerability Assessments Business Cntinuity Plans Disaster Recvery Plans Physical and Envirnmental Security Plicy User Accunt Terminatin Prcedures Cntingency Plan, including test prtcls 2011 CLOUD SECURITY ALLIANCE 76

78 Incident Reprting and Respnse Plan, including test prtcls Emergency Respnse Plan Facility Layut emergency exits, psitining f CCTV cameras, secure entry pints Fire Exit Rute Map and Fire Order Instructins Emergency Evacuatin Plan and Prcedures Crisis Cmmunicatin Prcedures Emergency Cntact Numbers User Facility Access Review/Audit Recrds Security Awareness Training dcumentatin, presentatin, handuts, etc. Security Awareness Attendance Recrds Successin Planning fr key executives Technical Dcuments electrical wiring diagrams, BMS, UPS, AHU details Maintenance Schedule f Electrical, Generatr, and CCTV Emergency fuel service prviders cntracts List f Authrized Persnnel allwed entry inside facility Security Staff prfiles bi and backgrund infrmatin Backgrund Check Reprts f Security Staff (must be perfrmed every year) SECURITY GUIDANCE FOR CRITICAL AREAS OF Annual Maintenance Cntracts fr key equipment and devices (fcus n SLA s 39 fr equipment/devices dwntime and restratin) When inspecting the dcuments, there are areas f critical fcus that the purchaser f clud services shuld fcus n t ensure that his/her risk is mitigated. The fllwing advice may prve critical in securing a clud cnsumer s business interest when transitining t clud: Check whether all the dcuments are up t date and current. These dcuments must be reviewed by the CSP at least nce a year. The revisin dates and sign ff by management must be included and validated as prf f them being reviewed internally. Further, the plicy and prcedure dcuments (that are suitable fr emplyee viewing) shuld be made available thrugh a cmmn Intranet site where authrized emplyees f the CSP can access them anytime fr reference. Adequate care must be taken by the security team t ensure the upladed dcuments are the latest versins duly apprved by management. 39 SLA - Service Level Agreement 2011 CLOUD SECURITY ALLIANCE 77

79 All plicies and prcedures will be effective nly when emplyees are aware f them. T this end, check whether a CSP has security awareness prgram in place. At the minimum, the CSP shuld ensure that emplyees are given adequate security awareness training at least nce each year and receive sign ff frm them. Als, new emplyees jining the rganizatin shall underg a security rientatin sessin as part f the inductin prgram where key plicies and prcedures are t be cvered with frmally signed attendance recrds maintained and available fr review at any time. T make the prgram effective, senir staff frm the security team must cnduct the sessin Cmpliance with Internatinal/Industry Standards n Security Ensure that the CSP is cmpliant with glbal security standards like ISO ISMS r ther industry-standards such as TOGAF, SABSA, ITIL, COSO, r COBIT. These activities will prve invaluable in assessing the CSP s level f security and its maturity. Verify the cmpliance certificate and its validity. Lk fr verifiable evidence f resurce allcatin, such as budget and manpwer t sustain the cmpliance prgram. Verify internal audit reprts and evidence f remedial actins fr the findings Visual Walk-Thrugh Inspectin f the CSP s facility Area Cverage Data Center Perimeter Security shuld be evaluated when determining what areas require physical cverage. The fllwing are high-risk areas that shuld be secured: Administrative areas Receptin Parking Area Strage Area Fire Exits CCTV Cmmand Center Air Handling Unit (AHU) Rm Lcker Rm UPS Rm Generatr Rm Fuel Strage Tanks 2011 CLOUD SECURITY ALLIANCE 78

80 Signage Lk fr the fllwing signage that must be displayed prminently in the facility at apprpriate places: Fire Escape Rute Maps and Emergency Exits Fire Order Instructins Fire Safety Signages Security Psters and instructins Anti-tailgating Psters Temperature/Humidity-related infrmatin Warning and Instructinal Signage Emergency Cntact Numbers Escalatin Chart Security Infrastructure Perimeter security is imprtant as it serves as the first line f prtectin against intruders and unwanted visitrs. The principles f perimeter security has undergne sea change with technlgical advancements. The Fur D s f Perimeter Security cnsists f Deter, Detect, Delay and Deny phases fr intruders wanting access t the facility. The fllwing qualities are preferential when selecting a physical infrastructure prvider. Depending n the design and functin f the clud service prvider, the fllwing list shuld be clsely adhered t in the selectin prcess. Due care shuld be taken t ensure the physical infrastructure is adequate fr the facility s size and nature and scale f peratins. Security cntrls must be strategically psitined and cnfrm t acceptable quality standards cnsistent with prevalent nrms and best practices. Secure Entry Pints Access cntrl systems (prximity cards/bimetric access) Access Cntrl System linked with fire cntrl panel fr emergency release Mtin-sensing alarms, thermal tracking devices, glass-breakage detectin Fire safety equipment wet riser, hydrants, hses, smke detectrs and water sprinklers Fire extinguishers Fire exits (must nt be lcked r blcked) Panic Bars in fire exit drs Alarm sirens and lights CCTV Cameras and DVR server (including backup timelines) 2011 CLOUD SECURITY ALLIANCE 79

81 Dr clsures and time-delay dr alarms Gas-based fire suppressants inside Data Centers Paper Shredders near printers Degaussing devices r disk shredders Emergency Respnse Team Kit (ERT Kit) Tw-way Radi devices (Walkie-talkie handsets) fr security staff Duress Alarms underneath security desk and vantage (cncealed) pints Dr Frame Metal Detectrs at entrance and Hand-held Metal Detectrs (if needed) Fire-prf Safe t safe keep imprtant dcuments/media 7.2 Human Resurces Physical Security The purpse f the human resurces physical cntrl is t minimize the risk f the persnnel clsest t the data disrupting peratins and cmprmising the clud. A knwledgeable actr with physical access t a cnsle can bypass mst lgical prtective measures by simply rebting the system r accessing a system that is already turned n with rt r administratr access. A wiring clset can prvide hidden access t a netwrk r a means t sabtage existing netwrks. Cnsider the fllwing measures: This sectin maps t Clud Cntrl Matrix Dmains IS-15, FS-05, FS-06, FS-07 and FS-08 as well as ISO/IEC Clause 9. Rles and respnsibilities (e.g., thrugh a RACI-style matrix) Backgrund verificatin and screening agreements Emplyment agreement (e.g., NDA s) Emplyment terminatin Awareness and training f cmpany plicies (i.e., Cde r Business Cnduct) Rles and respnsibilities are part f a clud envirnment, in which peple and prcesses, alng with technlgy, are integrated t sustain tenant security n a cnsistent basis. Segregatin f duties, requires at least tw persns with separate jb respnsibilities t cmplete a transactin r prcess end-t-end. Avidance f cnflict f interest is essential t the prtectin f clud cnsumers and measures shuld be implemented t mnitr r avid this risk. Segregatin f duties riginated in accunting and financial management; its benefits extend t ther risk mitigatin needs, such as physical security, availability, and system prtectin. Segregatin f duties is implemented via eliminating high-risk rle cmbinatins, e.g., nt having the same persn wh apprves a purchase rder als able t facilitate payment. The principle is applied t rle divisin in clud develpment and peratins, as well as a sftware develpment life cycle. An example cmmn t clud sftware develpment wuld be the separatin f thse wh develp applicatins frm the staff wh perate thse systems. Ensure there are n unauthrized backdrs remaining 2011 CLOUD SECURITY ALLIANCE 80

82 in the final delivered prduct. Ensure different persnnel manage different critical infrastructure cmpnents. Additinally, granting staff the least amunt f access privilege required fr them t perfrm their duties will further reduce but nt eliminate risk. The segregatin f duties and least privilege/access are principles that supprt a clud prvider s gal t prtect and leverage the rganizatin's infrmatin assets. A clud security management prgram requires the assignment f key rles and respnsibilities that may be held by individuals r grups. These rles and respnsibilities must be frmally defined in the rganizatin s infrmatin security plicy framewrk and frmally reviewed and apprved by senir management in line with their fiduciary GRC (Gvernance Risk and Cmpliance) duties and respnsibilities. Additinally, the develpment f effective HR security must include emplyment and cnfidentiality agreements, backgrund checks (when legally permitted), and legally sund hiring and terminatin practices. Additinal measures t cnsider, if they are applied acrss all areas f the rganizatin, include frmalized jb descriptins, apprpriate training, security clearances, jb rtatin, and mandatry vacatins fr staff in sensitive r high risk rles. 7.3 Assessing CSP Security Sme f the security risks assciated with clud cmputing are unique, partly due t an extended data centric chain f custdy, and it is in this cntext the business cntinuity, disaster recvery, and traditinal security envirnments f a clud service prvider need t be assessed thrughly and in reference t industry standards. Traditinal r Physical Security f the clud cmputing service prvider s facility is imprtant and needs t be thrughly assessed frm varius parameters. This is an area f highest similarity the security requirements f a clud and nnclud data center are fairly similar. A hlistic view and understanding f the peple, prcess, technlgy mdel r philsphy f the CSP wuld immensely help in evaluating the maturity f the CSP and flag pen issues with their apprach twards security which must be reslved, apprved, and clsed befre prceeding. Organizatinal maturity and experience cntributes a great deal t the effective handling f physical security prgrams and any cntingencies that may arise. Invariably, there is a strng human element invlved in the effective administratin f physical security prgrams. The level f management supprt and the caliber f the security leadership are significant factrs in prtecting cmpany assets with management supprt being critical. Physical security is generally the first line f defense against unauthrized as well as authrized access t an rganizatin s physical assets and the physical theft f recrds, trade secrets, industrial espinage, and fraud Prcedures Clud service prviders shuld ensure that the fllwing dcuments are made available fr inspectin n demand by clients: Backgrund Checks (nce yearly) by third party vendrs Nn-Disclsure Agreements Implement need t knw and need t have plicies fr infrmatin sharing 2011 CLOUD SECURITY ALLIANCE 81

83 Separatin f duties User Access Administratin Defined Jb Descriptin (Rle and Respnsibilities) Rle-based Access Cntrl System User Access Reviews Security Guard Persnnel Where human mnitring and interventin are necessary, physical security staff cmprised f guards, supervisrs and fficers shuld be psted (n 24/7 basis) at the CSP s facility. Amng ther things, the Site and Pst instructins shuld include the fllwing: Checking emplyee, cntract staff, and visitr credentials and use f the sign-in lg Issuing and recvering visitr badges Curbing tail-gating by emplyees Handling visitrs and mvement within the facility Handling security-relevant phne calls Mnitring intrusin, fire alarm systems and dispatch persnnel t respnd t alarms Cntrlling mvement f materials int and ut f the building and enfrcing prperty pass regulatins Enfrcing rules and regulatins established fr the building Patrlling inside facility CCTV mnitring Key cntrl and management Executing emergency respnse prcedures Escalating security-related issues t security manager Accepting and dispatching mail Escrting unattended business visitrs inside the ffice 2011 CLOUD SECURITY ALLIANCE 82

84 7.3.4 Envirnmental Security The CSP s facilities shuld prtect bth persnnel and assets by implementing cntrls that will prtect the envirnment frm envirnmental hazards. These cntrls may include but are nt limited t: temperature and humidity cntrls, smke detectrs and fire suppressin systems Envirnmental Cntrls The data center shuld be equipped with specific envirnmental supprt equipment accrding t published internal standards, lcal and/r reginal rules r laws including an emergency/uninterruptible pwer supply. Equipment/devices required fr envirnmental cntrls must be prtected t reduce risks frm envirnmental threats and hazards and t reduce the risk f unauthrized access t infrmatin Equipment Lcatin and Prtectin The fllwing cntrls must be cnsidered fr systems classified as cntaining Restricted r Cnfidential infrmatin: Equipment is lcated in a physically secure lcatin t minimize unnecessary access. Envirnmental cnditins such as humidity that culd adversely affect the peratin f cmputer systems are mnitred. Security staff shall take int accunt the ptential impact f a disaster happening in nearby premises, e.g., a fire in a neighbring building, water leaking frm the rf r in flrs belw grund level, r an explsin in the street. Methds fr thrughly destrying and dispsing f discarded media (e.g., disk drives) Equipment Maintenance T ensure cntinued availability and integrity, equipment is prperly maintained with equipment maintenance cntrls, including: Maintaining equipment in accrdance with the supplier s recmmended service intervals and specificatins Permitting nly authrized maintenance persnnel t carry ut repairs and service equipment Maintaining recrds f suspected r actual faults and all preventive and crrective maintenance. Using apprpriate cntrls when sending equipment ff premises fr maintenance. Examples f apprpriate cntrls include prper packaging and sealing f cntainers, strage in safe and secure places, and clear and cmplete shipping and tracking instructins. Maintaining apprpriate plicies and prcedures fr asset cntrl, including recrds retentin fr all hardware, firmware, and sftware encmpassing traceability, accuntability, and wnership A thrugh review f the CSP s facility wuld enable the prspective client t understand and evaluate the maturity and experience f the security prgram. Generally, with the fcus n IT security, physical security gets limited attentin. Hwever, with the range f threat scenaris prevalent tday it is imperative that the physical security receives the 2011 CLOUD SECURITY ALLIANCE 83

85 attentin it deserves, especially, in an envirnment where the clients data may be c-resident with a number f ther clients (including cmpetitrs), physical security assumes greater significance. Physical Security is ne f many intercnnected lines f defense against intruders and crprate sabteurs wh may want access t a CSP s facility fr nefarius purpses. 7.4 Business Cntinuity Traditinally, the three tenets f infrmatin security are cnfidentiality, integrity, and availability. Business Cntinuity deals with the cntinuity cmpnent f thse three requirements. The transitin t a Clud Service Prvider includes an assessment f the uptime the prvider cntractually cmmits t. Hwever, this Service Level Agreement (SLA) may nt be enugh t satisfy the custmer. Cnsideratin shuld be made t the ptential impact shuld a significant utage ccur. Based n recent high prfile service disruptins int third party prvisined services, the authrs wuld suggest that maintaining cntinuity f service is a critical dependency n the business t maintain peratins. The fllwing guidelines shuld be cnsidered with regard t maintaining the cntinuity f a given service. Althugh many f these guidelines will likely apply fr internally prvisined services as they wuld fr third party prvisined services (e.g. Clud), these guidelines are written with the pretext that the respnsibility rests with the third party. 7.5 Disaster Recvery One f the mst interesting aspects f clud strage fr IT is hw it can be leveraged fr backup and disaster recvery (DR). Clud backup and DR services are targeted at reducing the cst f infrastructure, applicatins, and verall business prcesses. Clud backup and DR must aim t make reliable data prtectin affrdable and easy t manage. The challenges t clud strage, clud backup, and DR in particular invlve mbility, infrmatin transfer t and frm the clud, availability, assuring ptimal business cntinuity, scalability and metered payment. Clud disaster recvery slutins are built n the fundatin f three fundamentals: a fully virtualized strage infrastructure, a scalable file system and a cmpelling self-service disaster recvery applicatin that respnds t custmers urgent business requirements. Custmers transitining disaster recvery peratins t the clud shuld review the existence f the fllwing rganizatins r teams within the service prvider s disaster recvery prgram: Emergency Respnse Team (ERT) Crisis Management Team Incident respnse team The cmpsitin f the abve teams shuld be reviewed in detail alng with crisis cmmunicatin prcedure Restratin Pririties Review the service prviders dcumented restratin plan: This plan shuld include details n the pririties regarding restratin sequencing. This shuld crrelate directly with the SLA, as cntractually cmmitted, with regards t the 2011 CLOUD SECURITY ALLIANCE 84

86 services acquired by the custmer and the criticality f the service. The Restratin plan shuld incrprate and quantify the RPO 40 (Recvery Pint Objective) and RTO 41 (Recvery Time Objective) fr services. Detail the Infrmatin security cntrls that are cnsidered and implemented during the restratin prcess, which shuld include as an example: Clearances f staff invlved during the restratin prcess Physical security cntrls implemented at alternate site Specified dependencies relevant t the restratin prcess (suppliers and utsurce partners) Minimum separatin fr the lcatin f the secndary site if the primary site is made unavailable 7.6 Permissins Ensure prper facility design. Adpt integrated physical and lgical security systems that reinfrce ne anther. Establish service level agreements that require the inheritance f emplyment security bligatins and respnsibilities by later levels f the supply chain. 7.7 Recmmendatins Plicy Recmmendatins Clud prviders shuld cnsider adpting as a security baseline the mst stringent requirements f any custmer, such that systems, facilities, and prcedures are at a system high level. T the extent these security practices d nt negatively impact the custmer experience, stringent security practices shuld prve t be cst effective and quantified by reducing risk t persnnel, revenue, reputatin, and sharehlder value. Alternately, prviders may target a set f users with lwer security requirements, r ffer a baseline level t all custmers with the ptential t up-sell and implement additinal measures fr thse wh value them. In the latter case, it shuld be recgnized that sme custmers will be interested nly in prviders that deliver unifrmly high security. This balancing act includes systems, facilities, and dcumented prcedures. Prviders shuld have rbust cmpartmentalizatin f jb duties, perfrm backgrund checks, require and enfrce nn-disclsure agreements fr emplyees, and restrict emplyee knwledge f custmers t a least privilege, need t knw basis. 40 RPO - Recvery Pint Objective 41 RTO - Recvery Time Objective 2011 CLOUD SECURITY ALLIANCE 85

87 7.7.2 Transparency Recmmendatins Transparency regarding the security psture f the CSP shuld be required. Onsite visit t the CSP s facility r data center will help in perfrming an n-the-spt assessment and gaining a clear understanding f the different security measures that have been put in place. Hwever, due t the n-demand prvisining and multi-tenant aspects f clud cmputing, traditinal frms f audit and assessment may nt be available, r may be mdified (e.g., shared access t a third-party inspectin). T enhance effectiveness f the nsite assessment, the visit t the CSP facility r data center shuld be carried ut unannunced (if need be with the CSP being infrmed abut a brad time windw rather than specific times). This will enable t have real assessment n the grund n a nrmal business day instead f giving an pprtunity t the CSP t keep up appearances during a client r third-party visit. When direct examinatin is pursued, the assessment team shuld cmprise at least tw members r mre with specialists drawn frm IT, Infrmatin Security, Business Cntinuity, Physical Security, and Management (e.g., department heads r data wners) functins. Custmers shuld request and acquire business cntinuity planning and disaster recvery dcumentatin prir t visit, including relevant certificatins (e.g., based n ISO, ITIL 42 standards), and audit reprts and test prtcls Human Resurces Recmmendatins Cnsumers shuld check t see if the CSP deplys cmpetent security persnnel fr its physical security functin. A dedicated security manager is highly recmmended t prvide the necessary leadership and drive t the physical security prgram. Leading industry certificatins such as CISA 43, CISSP 44, CISM 45, ITIL, r CPP 46 (frm ASIS 47 ) wuld be helpful in validating the incumbent s knwledge and skills in physical security. Cnsumers shuld request a thrugh review f the reprting structure f the security manager. This will help in determining whether the psitin has been given due significance and respnsibilities. The security manager shuld reprt t a functinal superir and his/her GRC Cmmittee if ne exists. They shuld nt reprt t Facilities r IT. It wuld be better if this psitin reprts t the CEO thrugh anther chain (e.g., thrugh the CRO r head cunsel) in terms f independence and bjectivity f the psitin Business Cntinuity Recmmendatins The custmer shuld review the cntract f third party cmmitments t maintain cntinuity f the prvisined service. Hwever, the custmer shuld strngly cnsider further analysis. Typically the custmer acts as the Data Cntrller and where persnal data is held, there are likely t be specific regulatry requirements t 42 ITIL - Infrmatin Technlgy Infrastructure Library 43 CISA - Certified Infrmatin Security Auditr 44 CISSP - Certified Infrmatin System Security Prfessinal 45 CISM - Certified Infrmatin Security Manager 46 CPP - Certified Privacy Prfessinal 47 ASIS - American Sciety fr Industrial Security 2011 CLOUD SECURITY ALLIANCE 86

88 ensure apprpriate cntrls are emplyed. Such requirements apply even in the event that a third party data prcessr is utilized. The custmer shuld review the third party Business Cntinuity prcesses and any particular certificatin. Fr example, the CSP may adhere and certify against BS 25999, the British Standard fr Business Cntinuity Management (BCM). The custmer may wish t review the scpe f the certificatin and dcumented details f the assessment. The custmer shuld cnduct an nsite assessment f the CSP facility t cnfirm and verify the asserted cntrls used t maintain the cntinuity f the service. It may nt be entirely necessary t cnduct this unannunced assessment f the CSP facility fr the sle purpse f verifying specific BCP cntrls, as typically such cntrls are nly likely t be engaged when a disaster/event were t ccur. The custmer shuld ensure that he/she receives cnfirmatin f any BCP/DR tests undertaken by the CSP. While many f the recmmendatins already mentined fcus n dcumented assertins that the service will maintain cntinuity, the true test f these is in the event f a significant incident. Withut awaiting an actual disaster t ccur, the custmer shuld stress the imprtance f getting frmal cnfirmatin f BCP/DR tests, and whether the tests satisfied the SLAs cntractually cmmitted Disaster Recvery Recmmendatins Clud custmers shuld nt depend n a singular prvider f services and shuld have a disaster recvery plan in place that facilitates migratin r failver shuld a supplier fail. IaaS prviders shuld have cntractual agreements with multiple platfrm prviders and have the tls in place t rapidly restre systems in the event f lss. Data validatin shuld be an autmated r user initiated validatin prtcl that allws the custmer t check their data at any time t ensure the data s integrity. Incremental backups shuld frequently update a replica f all prtected systems r snapshts at intervals set by the user fr each system, s the cnsumer determines the settings accrding t recvery pint bjectives. Full site, system, disk, and file recvery shuld be accessible via a user-driven, self-service prtal that allws the user the flexibility t chse which file disk r system they want t recver. The clud prvider shuld implement fast SLA-based data recvery. The SLA shuld be negtiated up frnt, and the custmer shuld pay fr the SLA required t ensure that there is n cnflict f interest. N data, n file r system disk, shuld take mre than 30 minutes t recver. WAN ptimizatin between the custmer and the physical site shuld be in place s that the clud enables full data mbility at reduced bandwidth, strage utilizatin, and cst CLOUD SECURITY ALLIANCE 87

89 7.8 Requirements All parties must ensure prper structural design fr physical security. All supply chain participants must respect the interdependency f deterrent, detective, and authenticatin slutins. End cnsumers must inspect, accunt fr, and fix persnnel risks inherited frm ther members f the clud supply chain. They must als design and implement active measures t mitigate and cntain persnnel risks thrugh prper separatin f duties and least privilege access CLOUD SECURITY ALLIANCE 88

90 DOMAIN 8 // DATA CENTER OPERATIONS In rder fr Clud Cmputing t evlve, the prvider must advance the enterprise data center beynd simply using virtualizatin t manage server assets. In rder t enable business agility, green technlgy, prvider penness, increasingly unique ideas in pwer generatin and data center cnstructin and management, the data center has t mrph fr lng-term clud success. The Next Generatin Data Center, a term that has been arund fr several years, has grwn int data center peratins that includes business intelligence adaptatin within the data center, understanding the applicatins running in the data center, and the requirement f hsting large scale analytical clusters are evlving as well. The data center is nt a standalne entity but an entity that needs t be as agile as the applicatin and als be cnnected t ther data centers s that latency is managed as well as security. Overview. This dmain will address the fllwing tpics: Physical security cnsideratins as related in the CCM Autmated data center use case mapping The new data center? Clud cmputing at hme CCM cnsideratins and hw new ideas in clud data center affect each ther Clud infrastructure disseminatin and the data center 8.1 Data Center Operatins New cncepts in this sectin: Clud Applicatin Missin. The industry r applicatin missin hused within the data center. Fr example, a health care r e-cmmerce applicatin missin. Data Center Disseminatin. Clud infrastructures that perate tgether but are in physically separate physical lcatins. Service based autmatin and predictive analytics t enable service-based autmatin have been lng represented by Infrmatin Technlgy Service Management 48 (ITSM) using Infrmatin Technlgy Infrastructure Library 49 (ITIL) standards fr data center evlutin. Different types f applicatins hused by data centers require autmatin. Thse wh perate the data center benefit greatly by understanding what is running inside it and hw the data center as a whle needs t respnd t varying use. 48 ITSM - Infrmatin Technlgy Service Management 49 ITIL - Infrmatin Technlgy Infrastructure Library 2011 CLOUD SECURITY ALLIANCE 89

91 The Clud Security Alliance s Clud Cntrls Matrix has a number f physical requirements based upn different standards and regulatry requirements. The physical security dmain in this versin f guidance and the Clud Cntrls Matrix shuld be read by the data center prfessinal t get an understanding f requirements inside and utside the data center. Fr reference, the fllwing table illustrates data center cntrls needed based upn the missin f the applicatins hused within the data center. The table is nt all-inclusive but prvides sme examples crss-referencing a Clud Cntrl Matrix cntrl and specificatin t an applicatin type r missin. Table 1 Applicatin Missin by Cntrl APPLICATION MISSION CONTROL SPECIFICATION Health Care (HIPAA 50 ) Card Prcessing/Payment (PCI 51 ) Pwer Generatin (NERC CIP 52 ) Facility Security -Security Plicy Facility Security - User Access Facility Security - Cntrlled Access Pints Plicies and prcedures shall be established fr maintaining a safe and secure wrking envirnment in ffices, rms, facilities and secure areas. Physical access t infrmatin assets and functins by users and supprt persnnel shall be restricted. Physical security perimeters (fences, walls, barriers, guards, gates, electrnic surveillance, physical authenticatin mechanisms, receptin desks and security patrls) shall be implemented t safeguard sensitive data and infrmatin systems. The list abve is nt meant t be exhaustive in this chapter. The reader can lk at the matrix and based upn the standards the rganizatin wants t abide by r which regulatins the rganizatin must adhere t can be seen there. An applicatin running in the data center that cntains regulated infrmatin (gverned under an infrmatin security r applicatin security standard) will be audited. The result f the physical audit findings undertaken by the data center peratr can then be published t the custmers f the data center peratr r included in an applicatin query infrastructure such as that prvided by Clud Audit. In past versins f the Guidance, the reader was instructed t cnduct their wn audits. Fr many data center peratrs r clud prviders this might nt be physically pssible. In multi-tenant envirnments the peratr r prvider cannt nrmally accmmdate visits by every custmer t cnduct an audit. The custmer shuld require the peratr r prvider t prvide independent audit results. This idea brings in service autmatin. By autmating reprting, lgging, and the publicatin f audit results the data center peratr can prvide their custmer with evidence that, based upn the applicatin missin, the data center 50 HIPAA - Healthcare Infrmatin Prtability and Prtectin Act 51 PCI - Payment Card Industry. Specifically PCI DSS, which is Data Security Standard 52 NERC CIP - Nrth American Electric Reliability Crpratin Critical Infrastructure Prtectin 2011 CLOUD SECURITY ALLIANCE 90

92 specific cntrls are in place and satisfactry. Clud Audit, Clud Trust Prtcl, and CYBEX (X.1500) can autmate the publicatin f audit findings thrugh a cmmn accessible interface. Further autmatin in the data center relies n the library that cntains the assets being hused with the data center. By understanding hw the assets in the library use resurces in the data center, the peratins management can predict which tenants are using resurces. If the data center uses cncepts such as PD s 53 and virtual data center VMDC 54 then the data center is as agile as it can be prmting the clud r virtualized business quickly New and Emerging Mdels Recently (Summer 2011) there was mre news abut hme-based clud platfrms. In these types f infrastructures mdeled after SETI@hme 55, a clud is based n the cmpute assets f vlunteers expsing their hme/ffice cmputers t supprt ther applicatins. The data centers in these cases are the hmes f each f the vlunteers. These types f cluds wuld wrk well as cmmunity-based applicatin hsting envirnments, but nt regulated envirnments where standards are audited. Fr example, if a clud is hsted n 100,000 hme cmputers there wuld be n way t audit a data center that is effectively cut up int 100,000 pieces and scattered acrss a large gegraphical area. This type f infrastructure wuld hst a cmmunity based set f applicatins based upn interest (bk club fr example) r a residential web site. The clud is increasingly being viewed as a cmmdity r as a utility. There are effrts in the industry t create Security as a Service r create brker infrastructures fr identity, interperability, and business cntinuity amngst ther reasns. The applicatin then is being pulled apart and placed int specialized physical envirnments that fcus n specific needs f an rganizatin r the applicatins they run. Data center disseminatin takes the applicatin and places it acrss many ther specialized data centers that huse and manage specific needs. By disseminating the applicatin acrss physical bundaries the applicatin is less burdened in the clud but harder t cntrl and manage. 8.2 Permissins Disseminatin f data center cllabratin. Data center autmatin having t span multiple physical unrelated data centers will need sftware t rchestrate what the data center needs fr lgging and reprt generatin during audits. Hme based cluds where the data center is persnal. Auditing fr standards and cmpliance are near impssible in hme based cluds. Regulated envirnments and standards based envirnments will have difficulty with hme-based cluds based n the cntrls needed. There may be aspects t an applicatin where sme part f the applicatin can be disseminated t hme-based infrastructure. 53 PD - Pint f Delivery. A rack-able aggregated set f pwer, cmpute, strage access, and netwrk cmpnents cntained in a single unit 54 VMDC - Virtual Multi-tenant Data Center. A cncept using mdular, easily rack-able cmpnents t quickly expand a data center such as PD s 55 SETI@hme CLOUD SECURITY ALLIANCE 91

93 8.3 Recmmendatins Organizatins building clud data centers shuld incrprate management prcesses, practices, and sftware t understand and react t technlgy running inside the data center. Organizatins buying clud services shuld ensure that the prvider has adpted service management prcesses and practices t run their data centers and have adpted racking techniques that ensure agile and highly available resurces inside the data center. Understand the missin f what is running in the data center. Given the cntrls in the Clud Cntrl Matrix the data center being built r purchased must cnfrm t physical and asset security requirements. Data center lcatins are imprtant. If technlgy and applicatin cmpnents are spread acrss data centers, then there will be latency between the data centers. Organizatins buying clud services must clearly understand and dcument which parties are respnsible fr meeting cmpliance requirements, and the rles they and their clud prvider when assessing cmpliance. 8.4 Requirements The Clud Security Alliance has many surces f infrmatin t help with the cnstructin r remdeling f data centers fr the clud. The cntrls matrix highlights requirements acrss a very brad set f security standards and regulatins. Clud Audit and ther prjects within the CSA als can help with cnstructin and management f data centers and the technlgy running within them. Fully understand Cntrl Matrix requirements based upn what is ging t run in the data center. Use a cmmn denminatr that satisfies mst applicatin missins. Use IT service management techniques t ensure availability, security, and asset delivery and management. If the data center is wned by a prvider, audit against a regulatry and security standard template and publish results t the custmer CLOUD SECURITY ALLIANCE 92

94 DOMAIN 9 // INCIDENT RESPONSE Incident Respnse (IR) is ne f the crnerstnes f infrmatin security management. Even the mst diligent planning, implementatin, and executin f preventive security cntrls cannt cmpletely eliminate the pssibility f an attack n the infrmatin assets. One f the central questins fr rganizatins mving int the clud must therefre be: what must be dne t enable efficient and effective handling f security incidents that invlve resurces in the clud? Clud cmputing des nt necessitate a new cnceptual framewrk fr Incident Respnse; rather it requires that the rganizatin apprpriately maps its extant IR prgrams, prcesses, and tls t the specific perating envirnment it embraces. This is cnsistent with the guidance fund thrughut this dcument; a gap analysis f the cntrls that encmpass rganizatins IR functin shuld be carried ut in a similar fashin. This dmain seeks t identify thse gaps pertinent t IR that are created by the unique characteristics f clud cmputing. Security prfessinals may use this as a reference when develping respnse plans and cnducting ther activities during the preparatin phase f the IR lifecycle. T understand the challenges clud cmputing pses t incident handling, we must examine, which challenges the special characteristics f clud cmputing and the varius deplyment and service mdels pse fr incident handling. This dmain is rganized in accrd with the cmmnly accepted Incident Respnse Lifecycle as described in the Natinal Institute f Standards and Technlgy Cmputer Security Incident Handling Guide (NIST ) [1]. After establishing the characteristics f clud cmputing that impact IR mst directly, each subsequent sectin addresses a phase f the lifecycle and explres the ptential cnsideratins fr respnders. Overview. This dmain will address the fllwing tpics: Clud cmputing impact n Incident Respnse Incident Respnse Lifecycle Frensic accuntability 9.1 Clud Cmputing Characteristics that Impact Incident Respnse Althugh clud cmputing brings change n many levels, certain characteristics [2] f clud cmputing bear mre direct challenges t IR activities than thers [3]. First, the n demand self-service nature f clud cmputing envirnments means that a clud custmer may find it hard r even impssible t receive the required c-peratin frm their clud service prvider (CSP) 56 when handling a security incident. Depending n the service and deplyment mdels used, interactin with the IR functin at the CSP 56 CSP - Clud Service Prvider 2011 CLOUD SECURITY ALLIANCE 93

95 will vary. Indeed, the extent t which security incident detectin, analysis, cntainment, and recvery capabilities have been engineered int the service ffering are key questins fr prvider and custmer t address. Secnd, the resurce pling practiced by clud services, in additin t the rapid elasticity ffered by clud infrastructures, may dramatically cmplicate the IR prcess, especially the frensic activities carried ut as part f the incident analysis. Frensics has t be carried ut in a highly dynamic envirnment, which challenges basic frensic necessities [4] such as establishing the scpe f an incident, the cllectin and attributin f data, preserving the semantic integrity f that data, and maintaining the stability f evidence verall. These prblems are exacerbated when clud custmers attempt t carry ut frensic activities, since they perate in a nn-transparent envirnment (which underscres the necessity f supprt by the clud prvider as mentined abve). Third, resurce pling as practiced by clud services causes privacy cncerns fr c-tenants regarding the cllectin and analysis f telemetry and artifacts assciated with an incident (e.g. lgging, netflw data, memry, machine images, and strage, etc.) withut cmprmising the privacy f c-tenants. This is a technical challenge that must be addressed primarily by the prvider. It is up t the clud custmers t ensure that their clud service prvider has apprpriate cllectin and data separatin steps and can prvide the requisite incident-handling supprt. Furth, despite nt being described as an essential clud characteristic, clud cmputing may lead t data crssing gegraphic r jurisdictinal bundaries withut the explicit knwledge f this fact by the clud custmer. The ensuing legal and regulatry implicatins may adversely affect the incident handling prcess by placing limitatins n what may r may nt be dne and/r prescribing what must r must nt be dne during an incident acrss all phases f the lifecycle [5]. It is advisable that an rganizatin includes representatives frm its legal department n the Incident Respnse team t prvide guidance n these issues. Clud cmputing als presents pprtunities fr incident respnders. Clud cntinuus mnitring systems can reduce the time it takes t undertake an incident handling exercise r deliver an enhanced respnse t an incident. Virtualizatin technlgies, and the elasticity inherent in clud cmputing platfrms, may allw fr mre efficient and effective cntainment and recvery, ften with less service interruptin than might typically be experienced with mre traditinal data center technlgies. Als, investigatin f incidents may be easier in sme respects, as virtual machines can easily be mved int lab envirnments where runtime analysis can be cnducted and frensic images taken and examined. 9.2 The Clud Architecture Security Mdel as a Reference T a great extent, deplyment and service mdels dictate the divisin f labr when it cmes t IR in the clud ecsystem. Using the architectural framewrk and security cntrls review advcated in Dmain 1 (see Clud Reference Mdel Figure 1.5.2a) can be valuable in identifying what technical and prcess cmpnents are wned by which rganizatin and at which level f the stack. Clud service mdels (IaaS, PaaS, SaaS) differ appreciably in the amunt f visibility and cntrl a custmer has t the underlying IT systems and ther infrastructure that deliver the cmputing envirnment. This has implicatins fr all phases f Incident Respnse as it des with all ther dmains in this guidance dcument. Fr instance, in a SaaS slutin, respnse activities will likely reside almst entirely with the CSP, whereas in IaaS, a greater degree f respnsibility and capability fr detecting and respnding t security incidents may reside with the 2011 CLOUD SECURITY ALLIANCE 94

96 custmer. Hwever, even in IaaS there are significant dependencies n the CSP. Data frm physical hsts, netwrk devices, shared services, security devices like firewalls and any management backplane systems must be delivered by the CSP. Sme prviders are already prvisining the capability t deliver this telemetry t their custmers and managed security service prviders are advertising clud-based slutins t receive and prcess this data. Given the cmplexities, the Security Cntrl Mdel described in Dmain 1 (Figure 1.5.1c), and the activities an rganizatin perfrms t map security cntrls t yur particular clud deplyment shuld infrm IR planning and vice versa. Traditinally, cntrls fr IR have cncerned themselves mre narrwly with higher-level rganizatinal requirements; hwever, security prfessinals must take a mre hlistic view in rder t be truly effective. Thse respnsible fr IR shuld be fully integrated int the selectin, purchase, and deplyment f any technical security cntrl that may directly, r even indirectly, affect respnse. At a minimum, this prcess may help in mapping f rles/respnsibilities during each phase f the IR lifecycle. Clud deplyment mdels (public, private, hybrid, cmmunity) are als cnsideratins when reviewing IR capabilities in a clud deplyment; the ease f gaining access t IR data varies fr each deplyment mdel. It shuld be self-evident that the same cntinuum f cntrl/respnsibility exists here as well. In this dmain, the primary cncern is with the mre public end f the cntinuum. The authrs assume that the mre private the clud, the mre cntrl the user will have t develp the apprpriate security cntrls r have thse cntrls delivered by a prvider t the user s satisfactin. 9.3 Incident Respnse Lifecycle Examined NIST [1] describes the fllwing main stages f the IR lifecycle: preparatin; detectin & analysis; cntainment, eradicatin & recvery. This sectin examines the specific challenges f clud cmputing fr these stages and prvides recmmendatins as t hw these challenges can be met Preparatin Preparatin may be the mst imprtant phase in the Incident Respnse Lifecycle when infrmatin assets are deplyed t the clud. Identifying the challenges (and pprtunities) fr IR shuld be a frmal prject undertaken by infrmatin security prfessinals within the clud custmer s rganizatin prir t migratin t the clud. If the level f IR expertise within the rganizatin is deemed insufficient, experienced external parties shuld be cnsulted. This exercise shuld be undertaken during every refresh f the enterprise Incident Respnse Plan. In each lifecycle phase discussed belw, the questins raised and suggestins prvided can serve t infrm the custmer s planning prcess. Integrating the cncepts discussed int a frmally dcumented plan shuld serve t drive the right activities t remediate any gaps and take advantage f any pprtunities. Preparatin begins with a clear understanding and full accunting f where the custmer s data resides in mtin and at rest. Given that the custmer's infrmatin assets may traverse rganizatinal, and likely, gegraphic bundaries necessitates threat mdeling n bth the physical and lgical planes. Data Flw diagrams that map t physical assets, and map rganizatinal, netwrk, and jurisdictinal bundaries may serve t highlight any dependencies that culd arise during a respnse CLOUD SECURITY ALLIANCE 95

97 Since multiple rganizatins are nw invlved, Service Level Agreements (SLA) 57 and cntracts between the parties nw becme the primary means f cmmunicating and enfrcing expectatins fr respnsibilities in each phase f the IR lifecycle. It is advisable t share IR plans with the ther parties and t precisely define and clarify shared r unclear terminlgy. When pssible, any ambiguities shuld be cleared up in advance f an incident. It is unreasnable t expect CSP s t create separate IR plans fr each custmer. Hwever, the existence f sme (r all) f the fllwing pints in a cntract/sla shuld give the custmer rganizatin sme cnfidence that its prvider has dne sme advanced planning fr Incident Respnse: Pints f Cntact, cmmunicatin channels, and availability f IR teams fr each party Incident definitins and ntificatin criteria, bth frm prvider t custmer as well as t any external parties CSP s supprt t custmer fr incident detectin (e.g., available event data, ntificatin abut suspicius events, etc.) Definitin f rles/respnsibilities during a security incident, explicitly specifying supprt fr incident handling prvided by the CSP (e.g., frensic supprt via cllectin f incident data/artifacts, participatin/supprt in incident analysis, etc.) Specificatin f regular IR testing carried ut by the parties t the cntract and whether results will be shared Scpe f pst-mrtem activities (e.g, rt cause analysis, IR reprt, integratin f lessns learned int security management, etc.) Clear identificatin f respnsibilities arund IR between prvider and cnsumer as part f SLA Once the rles and respnsibilities have been determined, the custmer can nw prperly resurce, train, and equip its Incident Respnders t handle the tasks that they will have direct respnsibility fr. Fr example, if a custmercntrlled applicatin resides in a PaaS mdel and the clud prvider has agreed t prvide (r allw retrieval f) platfrm-specific lgging, having the technlgies/tls and persnnel available t receive, prcess, and analyze thse types f lgs is an bvius need. Fr IaaS and PaaS, aptitude with virtualizatin and the means t cnduct frensics and ther investigatin n virtual machines will be integral t any respnse effrt. A decisin abut whether the particular expertise required is rganic t the custmer rganizatin r is utsurced t a Third Party is smething t be determined during the preparatin phase. Please nte that utsurcing then prmpts anther set f cntracts/nda s 58 t manage. Between all invlved parties, cmmunicatin channels must be prepared. Parties shuld cnsider the means by which sensitive infrmatin is transmitted between parties t ensure that ut-f-band channels are available and that encryptin schemes are used t ensure integrity and authenticity f infrmatin. Cmmunicatin during IR can be facilitated by utilizing existing standards fr the purpse f sharing indicatrs f cmprmise r t actively engage anther party in an investigatin. Fr example, the Incident Object Descriptin Exchange Frmat (IODEF) 59 [6] as well as the assciated Real-time Inter-netwrk Defense (RID) 60 standard [7,8] were develped in the Internet Engineering Task 57 SLA - Service Level Agreements 58 NDA - Nn-Disclsure Agreement 59 IODEF - Incident Object Descriptin Exchange Frmat 60 RID - Real-time Inter-netwrk Defense 2011 CLOUD SECURITY ALLIANCE 96

98 Frce (IETF) 61 and are als incrprated in the Internatinal Telecmmunicatin Unin s (ITU) 62 Cybersecurity Exchange (CYBEX) 63 prject. IODEF prvides a standard XML schema used t describe an incident, RID describes a standard methd t cmmunicate the incident infrmatin between entities, which includes, at least, a CSP and tenant. The mst imprtant part f preparing fr an incident is testing the plan. Tests shuld be thrugh and mbilize all the parties wh are likely ging t be invlved during a true incident. It is unlikely that a CSP has resurces t participate in tests with each f its custmers; the custmer shuld therefre cnsider rle-playing as a means t identify which tasking r requests fr infrmatin are likely t be directed at the CSP. This infrmatin shuld be used t infrm future discussins with the prvider while in the preparatin phase. Anther pssibility is fr the custmer t vlunteer t participate in any testing the CSP may have planned Detectin and Analysis Timely detectin f security incidents and successful subsequent analysis f the incident (what has happened, hw did it happen, which resurces are affected, etc.) depend n the availability f the relevant data and the ability t crrectly interpret that data. As utlined abve, clud cmputing prvides challenges in bth cases. Firstly, availability f data t a large extent depends n what the clud prvider supplies t the custmer and may be limited by the highly dynamic nature f clud cmputing. Secndly, analysis is cmplicated by the fact that the analysis at least partly cncerns nntransparent, prvider-wned infrastructure, f which the custmer usually has little knwledge and again by the dynamic nature f clud cmputing, thrugh which the interpretatin f data becmes hard, smetimes even impssible. Putting aside the technical challenges f incident analysis fr a mment, the questin n hw a digital investigatin in the clud shuld be cnducted in rder t maximize the prbative value (i.e. credibility) f the evidence at the time f writing remains largely unanswered. Hence, until legal cases invlving clud incidents have becme mre cmmn place and cmmnly accepted best practice guidelines exist, analysis results fr clud security incidents incur the risk f nt standing up in curt. Until standards, methds, and tls fr detecting and analyzing security incidents have caught up with the technical develpments intrduced by clud cmputing, incident detectin and analysis will remain especially challenging fr clud envirnments. Clud custmers must rise t this challenge by making sure that they have access t (1) the data surces and infrmatin that are relevant fr incident detectin/analysis as well as (2) apprpriate frensic supprt fr incident analysis in the clud envirnment(s) they are using Data Surces As in any hsted IT service integratin, the IR team will need t determine the apprpriate lgging required t adequately detect anmalus events and identify malicius activity that wuld affect their assets. It is imperative fr the custmer rganizatin t cnduct an assessment f what lgs (and ther data) are available, hw they are cllected and prcessed, and finally, hw and when they may be delivered by the CSP. 61 IETF - Internet Engineering Task Frce 62 ITU - Internatinal Telecmmunicatin Unin s 63 CYBEX - Cybersecurity Exchange 2011 CLOUD SECURITY ALLIANCE 97

99 The main data surce fr the detectin and subsequent analysis f incidents n the custmer side, is lgging infrmatin. The fllwing issues regarding lgging infrmatin must be taken int cnsideratin: Which infrmatin shuld be lgged? Examples f lg types that may be relevant are audit lgs (e.g. netwrk, system, applicatin, and clud administratin rles and accesses, backup and restre activities, maintenance access, and change management activity), errr lgs (e.g., kernel messages f hypervisrs, perating systems, applicatins, etc.), security-specific lgs (e.g., IDS lgs, firewall lgs, etc.), perfrmance lgs, etc. Where existing lgging infrmatin is nt sufficient, additinal lg surces have t be negtiated/added. Is the lgged infrmatin cnsistent and cmplete? A prime example f incnsistent surce lgging infrmatin is failure t synchrnize clcks f lg surces. Similarly, incmplete infrmatin regarding the time zne in which the timestamps in lgs are recrded makes it impssible t accurately interpret the cllected data during analysis. Is the clud s dynamic nature adequately reflected in the lgged infrmatin? The dynamic behavir f clud envirnments als is a frequent reasn fr incnsistent and/r incmplete lgging. Fr example, as new clud resurces (VM s, etc.) are brught nline t service demand, the lg infrmatin prduced by the new resurce instance will need t be added t the stream f lg data. Anther likely prblem is the failure t make dynamic changes in the envirnment explicit in the lg infrmatin. Fr example, cnsider the case that web service requests t a certain PaaS cmpnent are lgged, but may be serviced dynamically by ne f varius instances f this service. Incmplete infrmatin regarding the questin, which instance served which request, may then make prper analysis hard r impssible, e.g., if the rt cause f an incident is a single cmprmised instance. Are verall legal requirements met? Privacy issues regarding c-tenants, regulatin regarding lg data in general and persnally identifiable infrmatin in particular, etc., may place limitatins n the cllectin, strage, and usage f cllected lg data. These regulatry issues must be understd and addressed fr each jurisdictin where the cmpany s data is prcessed r stred. What lg retentin patterns are required? Legal and cmpliance requirements will direct specific lg retentin patterns. Clud custmers shuld understand and define any extended lg retentin patterns t meet their need ver time t supprt their requirements fr incident analysis/frensics. Are the lgs tamper-resistant? Ensuring that lgs are in tamper resistant stres is critical fr accurate legal and frensic analysis. Cnsider the use f write-nce devices, separatin f servers used t strage lgs frm applicatin servers and access cntrls t servers string lgs as critical aspects f this requirement. In which frmat is lgging infrmatin cmmunicated? Nrmalizatin f lgging data is a cnsiderable challenge. The use f pen frmats (such as the emerging CEE [9]) may ease prcessing at the custmer side. The clud prvider can nly detect sme incidents because such incidents ccur within the infrastructure wned by the clud prvider. It is imprtant t nte that the SLA s must be such that the clud prvider infrms clud custmers in a timely and reliable manner t allw fr agreed IR t ccur. Fr ther incidents (perhaps even detectable by the custmer) the clud prvider may be in a better psitin fr detectin. Clud custmers shuld select clud prviders that ptimally assist in the detectin f incidents by crrelating and filtering available lg data. The amunt f data prduced frm the clud deplyment may be cnsiderable. It may be necessary t investigate clud prvider ptins regarding lg filtering ptins frm within the clud service befre it is sent t the custmer t reduce netwrk and custmer internal prcessing impacts. Additinal cnsideratins include the level f analysis r crrelatin perfrmed by the CSP and the clud tenant t identify pssible incidents prir t frensics. If analysis is perfrmed at the CSP, the escalatin and hand-ff pints fr the incident investigatin must be determined CLOUD SECURITY ALLIANCE 98

100 9.3.4 Frensic and Other Investigative Supprt fr Incident Analysis SECURITY GUIDANCE FOR CRITICAL AREAS OF Althugh still immature, effrts are already underway within the frensic cmmunity t develp the tls and prtcls t cllect and examine frensic artifacts derived especially frm virtualized envirnments; als, frensic supprt required fr PaaS and SaaS envirnments is subject t nging research. It is imprtant that the custmer understands the frensic requirements fr cnducting incident analysis, researches t what extent CSP s meet these requirements, chses a CSP accrdingly, and addresses any remaining gaps. The amunt f ptential evidence available t a clud custmer strngly diverges between the different clud service and deplyment mdels. Fr IaaS services, custmers can execute frensic investigatins f their wn virtual instances but will nt be able t investigate netwrk cmpnents cntrlled by the CSP. Furthermre, standard frensic activities such as the investigatin f netwrk traffic in general, access t snapshts f memry, r the creatin f a hard disk image require investigative supprt t be prvided by the CSP. Als advanced frensic techniques enabled by virtualizatin such as generating snapshts f virtual machine states r VM intrspectin n live systems require frensic supprt by the CSP. With PaaS and SaaS security incidents that have their rt cause in the underlying infrastructure, the clud custmer is almst cmpletely reliant n analysis supprt f the CSP, and as mentined previusly, rles and respnsibilities in IR must be agreed upn in the SLAs. With PaaS, the custmer rganizatin will be respnsible fr any applicatin layer cde that is deplyed t the clud. Sufficient applicatin lgging is required fr incident analysis in scenaris where the rt cause lies within the applicatin (e.g., a flaw in the applicatin cde). In this case, supprt by the CSP culd take the frm f facilitating applicatin lg generatin, secure strage, and secure access via a read-nly API [10]. SaaS prviders that generate extensive custmer-specific applicatin lgs and prvide secure strage as well as analysis facilities will ease the IR burden n the custmer. This may reduce applicatin level incidents cnsiderably. Prviders that use their management backplane/systems t scpe an incident and identify the parts f a system that have been under attack r are under attack, and prvide that data t the clud custmer, will greatly enhance the respnse in all service mdels. T prepare fr incident analysis in a given clud envirnment, the custmer s IR team shuld familiarize themselves with infrmatin tls the clud vendr prvides t assist the peratins and IR prcesses f their custmer. Knwledge base articles, FAQs, incident diagnsis matrices, etc. can help fill the experience gap a clud custmer will have with regard t the clud infrastructure and its perating nrms. This infrmatin may, fr example, assist the IR team in discriminating peratinal issues frm true security events and incidents Cntainment, Eradicatin, and Recvery As with the ther phases f Incident Respnse, clse crdinatin with all stakehlders is required t ensure that strategies develped t cntain, eradicate, and recver frm an incident are effective, efficient, and take int cnsideratin all legal and privacy implicatins. The strategies must be als cnsistent with business gals and seek t minimize disruptin t service. This is cnsiderably mre challenging when multiple rganizatins are invlved in the respnse, as is the case with clud cmputing CLOUD SECURITY ALLIANCE 99

101 Optins fr this phase will differ depending upn the deplyment and service mdel, and als the layer f the stack at which the attack was targeted. There may be multiple strategies that can be emplyed, pssibly by different entities equipped with different technlgical slutins. If at all pssible, thught exercises shuld be cnducted in the preparatin phase t anticipate these scenaris and a cnflict reslutin prcess identified. Custmers must als cnsider hw their prvider will handle incidents affecting the prvider itself r affecting ther tenants n a shared platfrm in additin t incidents that are directly targeted at their wn rganizatin. Cnsumers f IaaS are primarily respnsible fr the cntainment, eradicatin, and recvery frm incidents. Clud deplyments may have sme benefits here. Fr example, islating impacted images withut destrying evidence can be achieved by pausing these images. As discussed in the intrductin, the relative ease with which ndes can be shut dwn and new instances brught up may help t minimize service interruptin when a cde fix needs t be deplyed. If there are issues with a particular IaaS clud, then the custmer may have the ptin f mving the service n t anther clud, especially if they have implemented ne f the meta-clud management slutins. The situatin is mre cmplicated fr SaaS and PaaS deplyments. Cnsumers may have little technical ability t cntain a Sftware r Platfrm as a Service incident ther than clsing dwn user access and inspecting/cleaning their data as hsted within the service prir t a later re-pening. But especially fr SaaS, even these basic activities may be difficult r impssible withut adequate supprt by the CSP, such as fine-grained access cntrl mechanisms and direct access t custmer data (rather than via the web interface). In all service mdels, prviders may be able t assist with certain categries f attack, such as a Denial f Service (DS) 64. Fr example, smaller enterprises may benefit frm the ecnmies f scale, which allw fr mre expensive mitigatin technlgies, such as DS prtectin, t be extended t their sites. As fr the previus phases, the extent t which facilities at the prvider will be made available t the custmer t assist in respnding t an attack shuld be identified in the preparatin phase. In additin, the cnditins under which the prvider is bligated t prvide assistance t respnding t an attack shuld be cntractually defined. The SLA s and the IR plan shuld be flexible enugh t accmmdate a Lessns Learned activity after the recvery. A detailed Incident Reprt based n the IR activities is t be written and shared with impacted parties, i.e., between the clud custmer, CSP and ther affected/invlved rganizatins. The Incident Reprt shuld include the timeline f the incident, analysis f the rt cause r vulnerability, actins taken t mitigate prblems and restre service, and recmmendatins fr lng-term crrective actin. Crrective actins are likely t be a blend f custmer-specific and prvider supprted, and the prvider s Incident Respnse team shuld prvide a sectin with their perspective f the incident and prpsed reslutin. After an initial review f the Incident Reprt by the custmer and CSP, jint discussins shuld be held t develp and apprve a remediatin plan. 9.4 Recmmendatins Clud custmers must understand hw the CSP defines events f interest versus security incidents and what events/incidents the clud-service prvider reprts t the clud custmer in which way. Event infrmatin that is supplied using an pen standard can facilitate the prcessing f these reprts at the custmer side. 64 DS - Denial f Service 2011 CLOUD SECURITY ALLIANCE 100

102 Clud custmers must set up prper cmmunicatin paths with the CSP that can be utilized in the event f an incident. Existing pen standards can facilitate incident cmmunicatin. Clud custmers must understand the CSP's supprt fr incident analysis, particularly the nature (cntent and frmat) f data the CSP will supply fr analysis purpses and the level f interactin with the CSP's incident respnse team. In particular, it must be evaluated whether the available data fr incident analysis satisfies legal requirements n frensic investigatins that may be relevant t the clud custmer. Especially in case f IaaS, clud custmers shuld favr CSP s that leverage the pprtunities virtualizatin ffers fr frensic analysis and incident recvery such as access/rll-back t snapshts f virtual envirnments, virtualmachine intrspectin, etc. Clud custmers shuld favr CSP s that leverage hardware assisted virtualizatin and hardened hypervisrs with frensic analytic capabilities. Fr each clud service, clud custmers shuld identify the mst relevant incident classes and prepare strategies fr the incident cntainment, eradicatin, and recvery incidents; it must be assured that each clud prvider can deliver the necessary assistance t execute thse strategies. Clud custmers shuld btain and review a CSP s histry fr incident respnse. A CSP can prvide industry recmmendatins frm existing custmers abut its IRP. 9.5 Requirements Fr each clud-service prvider that is used, the apprach t detecting and handling incidents invlving resurces hsted at that prvider must be planned and described in the enterprise incident respnse plan. The SLA f each clud-service prvider that is used must guarantee the supprt fr incident handling required fr effective executin f the enterprise incident respnse plan fr each stage f the incident handling prcess: detectin, analysis, cntainment, eradicatin, and recvery. Testing will be cnducted at least annually. Custmers shuld seek t integrate their testing prcedures with that f their prvider (and ther partners) t the greatest extent pssible. Ideally, a team (cmprising Custmer and CSP members) shuld carry ut varius health check tests fr an incident respnse plan, and accrdingly, suggestins shuld be implemented int a new versin f incident respnse plan CLOUD SECURITY ALLIANCE 101

103 REFERENCES [1] GRANCE, T., KENT, K., and KIM, B. Cmputer Security Incident Handling Guide. NIST Special Publicatin [2] MELL, P. and GRANCE, T. The NIST Definitin f Clud Cmputing, NIST Special Publicatin [3] GROBAUER, B. and SCHRECK, T. Octber Twards Incident Handling in the Clud: Challenges and Appraches. In Prceedings f the Third ACM Clud Cmputing Security Wrkshp (CCSW), Chicag, Illinis. [4] WOLTHUSEN, S Overcast: Frensic Discvery in Clud Envirnments. In Prceedings f the Fifth Internatinal Cnference n IT Security Incident Management and IT Frensics. [5] REED, J Fllwing Incidents int the Clud. SANS Reading Rm [6] DANYLIW, R., et al The Incident Object Descriptin Exchange Frmat, IETF Internet Draft RFC [7] MORIARTY, K Real-time Inter-netwrk Defense, IETF Internet Draft RFC [8] MORIARTY, K., and TRAMMELL, B Transprt f Real-time Inter-netwrk Defense (RID) Messages, IETF Internet Draft RFC [9] FITZGERALD, E., et al Cmmn Event Expressin (CEE) Overview. Reprt f the CEE Editrial Bard. [10] BIRK, D. and WEGENER, C Technical Issues f Frensic Investigatins in Clud Cmputing Envirnments In Prceedings f 6th Internatinal Wrkshp n Systematic Appraches t Digital Frensic Engineering (IEEE/SADFE), Oakland, CA, USA CLOUD SECURITY ALLIANCE 102

104 DOMAIN 10 // APPLICATION SECURITY Clud envirnments, particularly public clud envirnments, by virtue f their flexibility and penness challenge many fundamental assumptins abut applicatin security. Sme f these assumptins are well understd, hwever, many are nt. This sectin is intended t prvide guidance n hw clud cmputing influences security ver the lifetime f an applicatin, frm design t peratins t ultimate decmmissining. This guidance is fr all stakehlders (including applicatin designers, security prfessinals, peratins persnnel, and technical management) n hw t best mitigate risk and manage assurance when designing Clud Cmputing applicatins. Clud Cmputing is a particular challenge fr applicatins acrss the layers f Sftware as a Service (SaaS), Platfrm as a Service (PaaS) and Infrastructure as a Service (IaaS). Clud-based sftware applicatins require a design rigr similar t an applicatin cnnecting t the raw Internet the security must be prvided by the applicatin withut any assumptins being made abut the external envirnment. Hwever, the threats that applicatins are ging t be expsed t in a clud envirnment will be mre than thse experienced in a traditinal data center. This creates the need fr rigrus practices that must be fllwed when develping r migrating applicatins t the clud. Overview. This Applicatin Security dmain has been rganized int the fllwing areas f fcus: Secure SDLC 65 (General practices fr secure Sftware Develpment Life Cycle and nuances specific t the Clud) Authenticatin, Authrizatin, Cmpliance Applicatin Security Architecture in the Clud Identity and the cnsumptin f identity as it relates t Clud Applicatin Security Entitlement prcesses and risk-based access management as it relates t clud encryptin in clud-based applicatins Applicatin authrizatin management (plicy authring/update, enfrcement) Applicatin Penetratin Testing fr the Clud (general practices and nuances specific t clud-based Applicatins) Mnitring Applicatins in the Clud Applicatin authenticatin, cmpliance, and risk management and the repercussins f multi-tenancy and shared infrastructure The difference between aviding malicius sftware and prviding applicatin security 65 SDLC - Sftware Develpment Life Cycle 2011 CLOUD SECURITY ALLIANCE 103

105 10.1 Secure SDLC (Sftware Develpment Life Cycle) SECURITY GUIDANCE FOR CRITICAL AREAS OF A Secure Sftware Develpment Life Cycle (SSDLC) (als referred by a few as Secure Develpment Life Cycle (SDLC)) has assumed increased imprtance when migrating and deplying applicatins in the clud. Organizatins shuld ensure that the best practices f applicatin security, identity management, data management, and privacy are integral t their develpment prgrams and thrughut the lifecycle f the applicatin. Develping fr a clud envirnment is different than the traditinal hsting envirnments in the fllwing areas: The cntrl ver physical security is substantially reduced in public clud scenaris. The ptential incmpatibility between vendrs when services (fr example, Strage) are migrated frm ne vendr t anther. Prtectin f data thrugh the lifecycle must be cnsidered. This includes transit, prcessing and strage. The cmbinatins f web services in the clud envirnment can ptentially cause security vulnerabilities t be present. The ability t access lgs, especially in a shared public clud, is mre difficult and shuld be specified as a part f the service level agreement. Fail-ver fr data and data security in the clud has t be mre detailed and layered than traditinal envirnments. Assuring (and demnstrating evidence fr) cmpliance t relevant industry and gvernment regulatins is typically mre difficult within a clud envirnment. In implementing a SSDLC, rganizatins must adpt best practices fr develpment, either by having a gd blend f prcesses, tls, and technlgies f their wn r adpting ne f the maturity mdels such as these: Building Security In Maturity Mdel (BSIMM2) Sftware Assurance Maturity Mdel (SAMM) Systems Security Engineering Capability Maturity Mdel (SSE-CMM) Applicatin Security Assurance Prgram Organizatins shuld have an applicatin security assurance prgram that ensures fr the applicatins that are being migrated and/r develped and maintained in a clud envirnment the fllwing: With adequate executive supprt, gals and metrics are defined, implemented and tracked. A security and a privacy plicy fr applicatins in the clud has been established t meet the legal and regulatry cmpliance requirements that are aligned with the business needs and regulatry bligatins f the rganizatin CLOUD SECURITY ALLIANCE 104

106 Adequate capability and capacity fr security assurance is available within the rganizatin t architect, design, develp, test and deply secure applicatins by n-barding, training suitable resurces in a timely manner. Security and privacy risk evaluatins are perfrmed fr all applicatins t ensure the requirements are crrectly defined. Prcesses fr ensuring security and privacy requirements fr the develpment and maintenance prcess in the clud are defined and implemented. Cnfiguratin and change management must be auditable and verifiable Physical security risk evaluatins fr the applicatin and the data are perfrmed, and the access t all clud infrastructure cmpnents is adequate t meet thse requirements. Frmal cding best practices, cnsidering the strengths and weaknesses f language used shuld be fllwed during the develpment phase. Privacy and security measures must be auditable and verifiable Verificatin and Validatin Design Review Sme functins are mre security sensitive than thers and may nt be viable candidates fr running in the clud and shuld be cnsidered when the specific applicatin design and requirements are specified. The fllwing principles shuld be fllwed in rder t develp a secure design fr the applicatin. Where these principles cannt be met by a clud architecture, they shuld be remediated by apprpriate technical and/r cmpensating cntrls. Failure t d this brings int questin the viability f a clud deplyment. Least privilege. This principle maintains that an individual, prcess, r ther type f entity shuld be given the minimum privileges and resurces fr the minimum perid f time required t cmplete a task. In many cases, least privilege can nly be implemented effectively using fine-grained, cntextual applicatin authrizatin management with security plicy autmatin 66 mechanisms. Segregatin f duties. This is a cntrl plicy accrding t which n persn shuld be given respnsibility fr, r access t, mre than ne related functin. Defense in depth. This is the applicatin f multiple layers f prtectin wherein a subsequent layer will prvide prtectin if a previus layer is breached. Fail safe. If a clud system fails it shuld fail t a state in which the security f the system and its data are nt cmprmised. Fr example, t ensure the system defaults t a state in which a user r prcess is denied access t the system. Ecnmy f mechanism. This prmtes simple and cmprehensible design and implementatin f prtectin mechanisms, s that unintended access paths d nt exist r can be readily identified and eliminated CLOUD SECURITY ALLIANCE 105

107 Cmplete mediatin. This is where every request by an entity 67 t access an bject in a cmputer system must be authrized. Open design. This is an pen-access clud system design that has been evaluated and peer-reviewed by a cmmunity f experts resulting in a mre secure design. Least cmmn mechanism. This states that a minimum number f mechanisms (especially prtectin mechanisms) shuld be cmmn acrss multiple applicatins, minimizing ne applicatin s ability t crrupt r subvert anther applicatin. Weakest link. It is imprtant t identify the weakest mechanisms in the security chain and layers f defense and imprve them, s that risks t the system are mitigated t an acceptable level Cnstructin Cde Review It is recmmended t define and fllw secure sftware develpment at the rganizatin level. The guidelines spelled ut in the Fundamental Practices fr Secure Sftware Develpment frm SAFECde 68, CERT (SEI) 69 r ISO Standards culd be fllwed. Dynamic cde analysis examines the cde as it executes in a running clud applicatin, with the tester tracing the external interfaces in the surce cde t the crrespnding interactins in the executing cde, s that any vulnerabilities r anmalies that arise in the executing interfaces are simultaneusly lcated in the surce cde, where they can then be fixed. Unlike static analysis, dynamic analysis enables the tester t exercise the sftware in ways that expse vulnerabilities intrduced by interactins with users and changes in the cnfiguratin r behavir f envirnment cmpnents. Sme f the best practices fr writing a secure cde and reviewing are listed belw: The minimum necessary infrmatin shuld be included in clud server cde. Cmments shuld be stripped frm peratinal cde, and names and ther persnal infrmatin shuld be avided. Utilize surce cde analysis tls t check fr typical prgramming errrs such as Buffer Overflws, Frmat String Attacks, Race Cnditins, etc. Verify and validate all inputs, user, cmputer and inter-system. Cntent injectin and several ther attacks are pssible when the clud infrastructure takes any input and applies the cntent f that input int cmmands r SQL statements. When using bject cde (binaries), fr example, where 3rd party libraries are being used, utilize a testing service capable f static vulnerability testing n bject cde Security Testing 67 An entity culd be a user, cde, a device, an rganizatin r agent CLOUD SECURITY ALLIANCE 106

108 Penetratin test is a security testing methdlgy that gives the tester insight int the strength f the target s netwrk security by simulating an attack frm a malicius surce. The prcess invlves an active analysis f the clud system fr any ptential vulnerability that may result frm pr r imprper system cnfiguratin, knwn and/r unknwn hardware r sftware flaws, r peratinal weaknesses in prcess r technical cuntermeasures. This analysis is carried ut frm the psitin f a ptential attacker, and can invlve active explitatin f security vulnerabilities. The type f clud mdel has a huge impact n the penetratin testing r in deciding if penetratin test is pssible. Generally, Platfrm as a Service (PaaS) and Infrastructure as a Service (IaaS) cluds are likely t permit penetratin testing. Hwever, Sftware as a Service (SaaS) prviders are nt likely t allw custmers t penetratin test their applicatins and infrastructure, with the exceptin f third parties perfrming the clud prviders wn penetratin tests fr cmpliance r security best practices. Penetratin testing is typically carried ut within a black bx scenari, that is, with n prir knwledge f the infrastructure t be tested. At its simplest level, the penetratin test invlves three phases: 1. Preparatin. This is where a frmal cntract is executed cntaining nn-disclsure f the client s data and legal prtectin fr the tester. At a minimum, it lists the IP addresses t be tested. 2. Executin. In this phase the penetratin test is executed, with the tester lking fr ptential vulnerabilities. 3. Delivery. The results f the evaluatin are cmmunicated t the tester s cntact in the rganizatin, and crrective actin is advised. Whether the penetratin test is a full knwledge (white bx) test, a partial knwledge (gray bx) test, r a zer knwledge (black bx) test, after the reprt and results are btained, mitigatin techniques have t be applied t reduce the risk f cmprmise t an acceptable r tlerable level. The test shuld have the widest pssible scpe t address vulnerabilities and crrespnding risks t such areas as applicatins, remte access systems and ther related IT assets Interperability Testing Interperability testing evaluates whether a clud applicatin can exchange data (interperate) with ther cmpnents r applicatins. Interperability testing activities determine the capability f applicatins t exchange data via a cmmn set f exchange frmats, t read and write the same file frmats, and t cmmunicate using the same prtcls. A majr gal f interperability testing is t detect interperability prblems between clud sftware applicatins befre these applicatins are put int peratin. Interperability testing requires the majrity f the applicatin t be cmpleted befre testing can ccur. As well as testing fr interperability, these tests shuld cnfirm that all data exchanges, prtcls and interfaces used are using secure transfers f infrmatin. Interperability testing typically takes ne f three appraches: 1. Testing all pairs. This is ften cnducted by a third-party independent grup f testers wh are knwledgeable abut the interperability characteristics acrss sftware prducts and between sftware vendrs. 2. Testing sme f the cmbinatins. This invlves testing nly part f the cmbinatins and assuming the untested cmbinatins will als interperate CLOUD SECURITY ALLIANCE 107

109 3. Testing against a reference implementatin. This establishes a reference implementatin, e.g., using the accepted standard, and testing all prducts against this reference Quantitative Imprvement Metrics Any applicatin security assurance prgram shuld cllect metrics, which can be analyzed and used t reprt the status f secure develpment n a peridic basis. The metrics cllectin and reprting culd be enhanced as any applicatin security prgram attains mre maturity. Sme f the metrics recmmended are: Percentage f applicatins and data assets in the clud evaluated fr risk classificatin in the past quarter and/r year Csts f the Applicatin Security Assurance prgram in a quarter and/r in a year in a prject/prgram fr cludbased applicatins Estimates f past lss due t security issues, if any, in the applicatins being develped and/r deplyed in the clud Use f Autmated SDLC Security Technlgy Tls and Features Peple-centric SDLC activities (prcesses, training, and testing) are necessary but ften nt sufficient r viable fr gd applicatin security. Where feasible, autmated tls shuld be used t cnstruct secure applicatins and autmatically build security int applicatins. Such tls that autmatically generate technical security features are ften tied int develpment and integratin/rchestratin tls. Fr example, technical authrizatin plicy rules can be autmatically generated (at develpment/integratin/mash-up time) frm security requirement specificatins by tls that analyze applicatins and their interactins 70. Similarly, sme autmated testing can be dne at the develpment/integratin stage, and infrmatin assurance evidence can be generated. Fr clud, this can be dne at the subscriber end during develpment r mash-up (especially fr IaaS), r the clud prvider can prvide the technlgy (the subscriber can cnfigure if necessary), especially in the clud applicatin platfrm fr PaaS. Fr SaaS, it is likely that mst security autmatin will be built-in, cnfigured, and perated by the clud prvider. 70 This scientific field is called mdel-driven security, see CLOUD SECURITY ALLIANCE 108

110 10.2 Authenticatin, Authrizatin, and Cmpliance Applicatin Security Architecture in the Clud Clud Services/Applicatins Develpment and Business Challenges There are new ptential risks assciated with access t sensitive data and systems. A clear understanding f the fllwing security risks within the applicatin and business envirnment is critical fr addressing the full scpe f security and privacy issues in reference t the Clud services/applicatins: Lack f cntrl. This is where clud subscribers typically lack cntrl ver clud security plicies and cntrls. Lack f visibility. This is where clud subscribers typically lack visibility int clud security plicy enfrcement and cntrls effectiveness. Lack f manageability. This is where clud subscribers are ften nt sufficiently able t manage clud applicatin security, especially access and audit plicies. Lss f gvernance. This is where the rganizatin may nt have direct cntrl f the infrastructure; here trust in the prvider (smetimes a naive trust) and its wn ability t prvide prper security is paramunt. Cmpliance risk. This is where the clud prvider impacts the rganizatin's ability t cmply with regulatins, privacy expectatins, and industry standards, because data and systems may exist utside the rganizatin's direct cntrl. Islatin failure. This is where multi-tenancy and resurce sharing are defining characteristics f the clud. Thus it is entirely likely fr cmpeting cmpanies t be using the same clud services, in effect, running their wrklads shulder-t-shulder. Keeping memry, strage, and netwrk access islated is essential. Data prtectin. This is where the rganizatin relinquishes direct cntrl ver data; it relies n the prvider t keep that data secure, and when it is deleted, the prvider shuld ensure (r be able t prve) that it is permanently destryed. Management interfaces and access cnfiguratin. Clud applicatins are accessed and managed thrugh the Internet, and ptentially invlve cmplex and cntrl requirements. The risk assciated with a security breach is therefre increased and prper access authrizatin must be carefully cnsidered Technical Risks and Slutins Mst Clud service prviders include sme frm f Identity, Entitlement, and Access Management (IdEA) 71 in the clud service s design. Often user authenticatin and authrizatin is delegated t the custmer s user management system using a federatin standard. 71 IdEA - Identity, Entitlement, and Access Management 2011 CLOUD SECURITY ALLIANCE 109

111 Supprt fr Identity, Entitlement and Access Management impacts the custmer in that integratin in cnstrained by the credential passing mechanism. Infrastructure such as billing and metering that depend n identity management als present integratin and migratin risks. Supprt fr Identity, Entitlement, and Access management has integratin implicatins fr the custmer. These implicatins include securely passing credentials and attributes, prvisining additinal users, etc. Business peratins within the clud service prvider are als affected; these peratins include billing and accunting resurce utilizatin. As a result, it is imprtant t cnsider Identity, Entitlement, and Access management integratin as an integral part f the design. The applicatin s IdEA capabilities (r lack theref), such as an applicatin s ability t accept a SAML 72 assertin, will impact the clud service gvernance, integratin, and user experience, thus understanding the IdEA requirements f the particular clud applicatin is a critical part f the requirements definitin. Typical IdEA requirements in a clud applicatin design include: Understanding hw the clud applicatin will prvisin accunts t users, pwer users, and administratrs triggers fr these culd be links t internal HR systems r clud-based HR platfrms Prvisining f clud services fr service-t-service integratin, e.g., internal applicatins t clud-based services The ability t accept claim and assertins (identifiers and attributes) frm a variety f surces, and entities based n federatin standards (e.g., SAML, WS FED, etc.) The ability t make risk-based entitlement decisins abut access t (and within) the clud applicatin, based n the identity and attributes f all the entities (users, devices, cde, rganizatin, agents) in the chain. A rich, risk-based entitlement language leading t access management (authring/distributin/update, etc.) fr prtected resurces (i.e., what is allwed fr each resurce) Supprt fr internal security and regulatry-plicy cmpliance requirements, such as claims-based authenticatin, r at a minimum rle-based access cntrl User activity mnitring, lgging, and reprting dictated by internal plicies and regulatry cmpliance, such as SOX, PCI, and HIPAA. A variety f Identity prviders r Service prviders may generate tkens such as SAML, OpenID 73, r OAuth 74 tkens fr sessin caching allwing a pass-thrugh sign-n capability. Applicatins t be deplyed in clud shuld have capability t integrate with these claims/assertin services and Applicatins/services shuld be designed t supprt the pen standards fr Federatin, i.e. SAML, OAuth, OpenID. 72 SAML - Security Assertin Markup Language, an XML-based OASIS pen standard fr exchanging authenticatin and authrizatin data between security dmains 73 OpenID - an pen standard permitting users t be authenticated in a decentralized manner 74 OAuth - Open Authrizatin, an pen standard fr authrizatin, allwing users t share their private resurces with tkens instead f credentials 2011 CLOUD SECURITY ALLIANCE 110

112 The Entitlement management prcess will require the ability fr defining, managing, and accessing the access cntrl rules fr the clud-based applicatins thrugh a centralized interface. Such an interface/service culd itself be hsted n the clud r internally and can leverage standards such as XACML 75. The main challenge here is manageability: With increasing security plicy and cmpliance cmplexity, IT cmplexity, and IT agility, the task f translating security plicies int security implementatin gets mre time-cnsuming, repetitive, expensive, and errr-prne and easily can amunt t the bulk f security csts fr end-user rganizatins as traditinal users are managed int and ut f access cntrl lists fr rle-based access cntrl, while expensive engines prcess these lists t ensure segregatin-f-duties have nt been breached. Instead, defining a set f rules int an entitlement layer, fed by the claims, (assertins,) and attributes f the entities in the transactin significantly simplifies and enhances the cntrl an rganizatin has ver its applicatins leading t the end subscriber rganizatins (and clud prviders) lwering their cst and imprving plicy implementatin accuracy. Table 1 Simple Entitlement Matrix fr a Clud HR Applicatin Claim / Attribute Crprate HR Managers Access User Crprate Access Crprate HR Managers Hme Access (Crp. Laptp) User Hme Access (Own Device) ID: Organizatin Id Valid Valid Valid N ID: User Identifier Valid Valid Valid Valid ID: Device Valid Valid Valid N Attrib: Device is clean Valid Valid Valid Unknwn Attrib: Device is patched Valid Valid Valid Unknwn Attrib: Device IP (is n crp. net.?) Valid Valid N N Attrib: User is HR manager Valid N Valid N Access Result Read/write access t all HR accunts Read/write access t users HR accunt nly Read/write access t users HR accunt nly Read-nly access t users HR accunt nly T integrate applicatin security cntrls, data security and privacy prtectin, the services shuld use auditable industry standards, e.g. ISAE 3402/SSAE 16 (replaces SAS 70), PCI, HIPAA and ISO Each ne cmes with cntrls in a variety f categries that gvern peratin f a clud prvider s data center as well as the applicatins that can be hsted in such an envirnment. It is imprtant t evaluate the different security claims and make a sund decisin n which standards apply fr the applicatins and services being hsted in a clud envirnment. A thrugh analysis based n requirements shuld be dne t identify service level bjectives upfrnt t avid majr cde changes t applicatin cde, deplyment, and supprt tls fr bth the custmers as well as the clud prvider rganizatins. 75 XACML- extensible Access Cntrl Markup Language, an OASIS standard 2011 CLOUD SECURITY ALLIANCE 111

113 Cmpliance Building Blcks Irrespective f which standards are used, achieving cmpliance t run an applicatin in a clud has sme basic building blcks and the fundatin f all standards is prvided by the clud prvider s physical infrastructure. Infrastructure cntrls include things like prtecting the facility frm natural disasters, assuring reliable electrical pwer in the event f utages, and backing up data in the event f a hardware failure. They als include cntrls gverning the clud prvider s prcesses and plicies such as system administrative auditing, access and authrizatin t access the data center, and methds used fr internal security reviews and hw they are perfrmed and reprted. The next layer n tp f the infrastructure cntrls is a cllectin f applicatin cntrls. Multiple levels f security are required, such as the transprt layer that must be secure; when data leaves the data center, it must be encrypted with encryptin keys under enterprise cntrl. Sme applicatins may need message layer security, digital signing, and ther added security features in rder t be cmpliant with sme standards fr string r transmitting Persnally identifiable infrmatin in rder t meet privacy requirements. All such applicatin cntrls fr the service/applicatin t be mved t Clud shuld be identified during the design phase s they can be apprpriately integrated int the architecture design and develped as per requirements. Ntable standards are PCI DSS, SOX, ISAE 3402/SSAE 16,HIPAA, and ther privacy standards Identity, Entitlement, & Access Management fr Clud Applicatin Security Traditinal in huse enterprise applicatins culd be prtected with traditinal edge security cntrls like firewalls, prxies, etc. This culd very well meet the risk level and security requirements f the enterprise as the applicatins are running n trusted netwrks, trusted hardware, etc. The enterprise culd als leverage their enterprise directry infrastructure fr authenticating its users t these applicatins and maintain all access decisins within the applicatins. The perimeter fr the enterprise is well defined in this case. When the user mves these applicatins t the clud, all these traditinal cntrls are n lnger effective enugh t prtect as these applicatins are running n un-trusted netwrks (de-parameterizatin). Applicatins culd be residing with ther c-tenants f same service prvider (resurce pling) and culd be accessed frm anywhere thrugh any type f device. This changes the very nature f security requirements fr the clud applicatins. As per clud anatmy is referred as the fllwing: 2011 CLOUD SECURITY ALLIANCE 112

114 Figure 1 Clud Anatmy SECURITY GUIDANCE FOR CRITICAL AREAS OF T the abve referenced structure the user can nw add the ways he/she can access these applicatins. This anatmy can then be viewed as: Figure 2 Clud Delivery Cmpnents Frm the anatmy abve, yu can clearly see that yur applicatin is a windw t yur data, and the new perimeter is the cntent (data) and cntext by which the user tries t access that data. This makes applying security cntrls t the clud applicatins critical. The cntext f accessing the data becmes very imprtant and needs a rich cllectin f identifiers and attributes with which t make access decisins. With cnsumerizatin f IT, enterprises are nw faced with the reality f Bring Yur Own Device (BYOD). S device identificatin and the attributes f that device als becme an imprtant factr fr determining the access cntrl. Identity shuld nt just be viewed as a reference fr authenticating the entity but als gathers mre infrmatin abut the user fr making access decisins. Identity als includes the identities f the devices that applicatins run n (VM image identity), privileged users that manage that VM image (culd be bth enterprise users as well as service prvider users), identities fr ther applicatins and services that applicatin needs t interact with, identities f administrative users t manage the applicatin, and external identities utside f the enterprise that need access t the applicatin like B2B, B2C, etc. Als nte that access decisins will be based n attributes that are nt identity-related, and plicy authring/management tls need t supprt such nn-identity attributes (see Authrizatin management & plicy autmatin belw). In this sectin we will lk int hw Identity, Entitlement, and Access management affects the clud applicatin security. IdEA can be divided bradly int five main cmpnents: 1. Authenticatin 2. Authrizatin 3. Administratin 4. Audit & Cmpliance 5. Plicy 2011 CLOUD SECURITY ALLIANCE 113

115 Authenticatin Authenticatin refers t establishing/asserting the identity t the applicatin. This is usually dne in tw phases. The first phase is disambiguating the identity and the secnd phase is validating the credential already prvided t the user. Sme f the main drivers fr authenticatin t clud applicatins are device independence, cmmn and simple UI, and single prtcl universal acrss the devices. Als, many service prviders expse their services in frm f API s 76, and these API s are designed fr accepting tkens rather than the passwrds. In a regular enterprise applicatin, the authenticatin is dne against the enterprise user stre (Active Directry r LDAP), and the authenticating credential is typically userid/passwrd. Fr clud-based applicatin, authenticating using the enterprise credentials gets trickier. Sme enterprises establish VPN tunnel frm the service prvider t the enterprise netwrk s that they can authenticate against the enterprise user directry. Even thugh this slutin might wrk, enterprise shuld take int cnsideratin latency issues, cnnectivity issues, and BCP/DR planning etc., and this slutin shuld nt be used r designed int new clud applicatins. Enterprises shuld plan fr using pen standards like SAML and WS-Federatin. There is als increase in use f enterprise applicatins by partners and custmers f the enterprise. This is als true fr clud applicatins. These users rarely want t maintain separate identities fr their 3 rd party access (but tday ften have n chice). S enterprises shuld plan fr Bring Yur Own Identity (BYOI), and the clud applicatin needs t be designed t cnsume Identity and attributes frm multiple rganizatins. Since the clud applicatins are accessible widely thrugh varius devices, authenticating with simple userid/passwrd shuld be deprecated as a slutin. Enterprises shuld plan fr using strnger authenticatin. Cnsumers shuld cnsider strng authenticatin fr the riginal identity cnfirmatin and determine the type f credential that meets their risk requirement (RSA tken, OTP ver SMS r phne, Smartcard/PKI, Bimetrics etc.). This then will enable identifiers and attributes with a strng level f authenticatin t be passed t the clud applicatin and better risk decisins t be made abut access management by the entitlement layer. Enterprises shuld plan fr using risk-based authenticatin fr their clud applicatins. This type f authenticatin is based n device identifier, gelcatin, ISP, heuristic infrmatin, etc. Clud applicatin shuld nt nly perfrm authenticatin during the initial cnnectin but shuld als perfrm risk-based authenticatin based n the transactins being perfrmed within the applicatin. Clud applicatins shuld als leverage cnvergence f standards where applicable, such as SAML and OAuth. As mentined earlier in this sectin, clud service API s are designed t accept tkens and nt passwrds, s a user trying t access clud services frm their mbile device first has t authenticate t their Identity Prvider (tday, prbably their enterprise), and a SAML assertin is generated and passed n t clud service prvider. Upn successful validatin f the SAML assertin, an OAuth tken is generated and passed n t the mbile device. The mbile device then passes n these tkens t access clud services REST 77 based API s. 76 API - Applicatin Prgram Interface 77 REST - Representatinal state transfer, a style f sftware architecture fr distributed hypermedia systems 2011 CLOUD SECURITY ALLIANCE 114

116 Authrizatin and Access Cntrl Authrizatin in bradest terms refers t enfrcing the rules by which access is granted t the resurces. The Entitlement prcess implements business plicies that in turn translate t access int enterprise resurces. Fr cludbased applicatins, authrizatin shuld nt nly be perfrmed based n the cntent but als by the cntext. Fr user-centric authrizatin mdel, the user is the Plicy Decisin Pint (PDP) 78. The user determines the access fr their resurces, and the service prvider acts as Plicy Enfrcement Pint (PEP) 79. OAuth is widely used fr this mdel, and User Managed Access (UMA) is als an emerging standard in this space. Fr an enterprise-centric authrizatin mdel, the enterprise is the PDP r Plicy Access Pint (PAP) 80, and the service prvider acts as PEP. In sme cases, enterprises implement clud security gateways fr PEP. The enterprise custmer shuld cnsider use f XACML and centralized plicy management. Clud applicatins culd be leveraging multiple types f services. Sme services culd be legacy applicatins expsed as web services utilizing middleware, r the web services culd be native clud web services. The diversity f the delivery supply chain, althugh abstracted by the web service interface, may cmplicate the gvernance prcess. Design time gvernance includes defining the services, develping the services, registering the services, and implementing plicy requirement fr accessing these services. Runtime gvernance includes discvering the services, implementing security restrictins fr calling the services, enfrcing security restrictins fr accessing the service, and auditing all access. Use pen standards like W3C WS 81 -plicy fr defining security and management plicy assertins, WS-security fr enfrcing access restrictins, WS-trust fr implementing Secure Tken Service (STS) 82 t validate and issue tkens, and exchange tken frmats, etc. There are different types f authrizatin mdels namely Rle-based, Rule-based, Attribute-based access, Claims-based, and Authrizatin-based access cntrl (such as ZBAC) 83. Enterprises that already wn Web Access Management (WAM) 84 slutin shuld leverage these slutins t seamlessly prtect clud applicatins as well. Mst f WAM prducts supprt Rule and Rle-based access cntrls. Applicatin architects and designers shuld plan t migrate t Rule-based using claims and attributes as the surce fr thse rules via the Entitlement prcess described abve, and depreciate ther legacy slutins. When using attribute-based access cntrl, the Identity Prvider (IdP) 85 passes attributes t the Clud Service Prvider fr enfrcement. Identity Prviders shuld ensure: Attributes attached t the identity need nt strictly refer t the user identity such as first name, last name, address, etc. It culd als include IP address, lcatin infrmatin, grup affiliatin, phne number, etc. Care shuld be taken fr sharing attributes that directly identify the user as it raises privacy issues. 78 PDP - Plicy Decisin Pint 79 PEP - Plicy Enfrcement Pint 80 PAP - Plicy Access Pint 81 WS - Web Service 82 STS - Secure Tken Service 83 Described in publicatins by Alan Karp, HP Labs 84 WAM - Web Access Management 85 IdP - Identity Prvider 2011 CLOUD SECURITY ALLIANCE 115

117 Enterprises shuld als plan fr the attribute cmplexity fr making access cntrl decisins. They shuld knw which attribute prvider t cntact fr a particular attribute-based n authritativeness. There are attribute aggregatrs that enterprise can leverage. This culd either cmplicate r simplify the trust. Enterprises shuld take int accunt cnflict reslutin cmplexities, handling incmplete data, etc. Enterprises shuld als take int accunt attribute extensibility like validatin (verifiability), terms f use, date, etc. Enterprises shuld take int cnsideratin privacy, attribute release plicies, and cnsent. Examples include EU privacy directives, State and lcal laws, etc. Lcatin f the IdP, CSP, and user (jurisdictinal issues) shuld als be factred int this decisin. Only minimal infrmatin required fr the access cntrl shuld be released. Enterprises shuld ensure attributes that are nt identity-centric are als supprted. Enterprises shuld ensure that access plicies and entitlement plicies are manageable in additin t being technically enfrceable. Ptential slutins include the use f plicy autmatin technlgies (maybe tied int the PaaS applicatin mash-up tls). The main gal f Claims-based access cntrl is cntrlled sharing f the infrmatin. The claims are based n the cntext f the transactin. When planning t use claims-based authrizatin, an enterprise shuld cnsider: Usage f meaningful claims (verified address instead f just address) Type, surety, freshness, and quality f the claim (if the claim is cached utside f claims prvider then the freshness f the claim is lst). Apprpriate authrity f the claims based n the cntext, e.g., a telecm cmpany having authrity t verify yur phne number, an prvider having authrity t verify yur address, etc. Utilizatin f claim brkers where pssible as they culd be used fr abstractin frm varius claims prviders, e.g., they culd create a package f claims at desired cnfidence levels and create a central pint fr user permissin Minimal release f claim as required by the transactin The clud applicatin culd als be a mash-up f ther clud applicatins running n the same r different service prviders. The enterprise shuld plan fr hw the users are authenticated seamlessly acrss all these clud applicatins and hw the users prfiles such as grup assciatin, entitlements, rles, etc. are shared acrss these clud applicatins fr granular access cntrls. Enterprises are recmmended t use pen standards fr this use case (SAML, OAuth, XACML, etc.) CLOUD SECURITY ALLIANCE 116

118 Administratin/Management Identity Management (IDM) 86 within the enterprise is mainly fcused n managing users (prvisining) and managing access plicies (fr enterprise applicatins). IDM is a very imprtant cmpnent f IdEA fr nt nly prviding timely access t the users but als timely revcatin f access when the user leaves r timely management f access when the user mves t a different rle. Within the enterprise, identity management is usually tightly integrated and is directly cnnected t the data stres (users, plicies, etc.); in mst deplyments, it is als heavily custmized. Due t the distributed nature f clud applicatins applying the same principle becmes a nn- starter, as IDM might nt have direct access t the data stres n the service prvider. Mrever, there are n standard API s fr prvisining. Many service prviders have nt adpted Service Prvisining Mark-up Language (SPML) 87. IDM in the cntext f clud cmputing shuld nt nly manage the user identities. It shuld extend this t manage clud applicatin/services identities, access cntrl plicies fr these clud applicatins/services, privileged identities fr the applicatins/services, etc. Current federated prvisining is implemented with prprietary API s expsed by the service prvider. The PUSH mdel that is fllwed by the enterprise IDM will nt wrk with clud applicatins as it might verlad the service prviders. The new emerging standard is Simple Clud Identity Management (SCIM) 88 with the main gal f this standard t make the management f identities cheaper with easier and faster implementatin. The secndary gal is t ease the migratin f user identities int and ut f the clud. SCIM is simple because it uses well defined cre schema, cludfriendly because it uses RESTful API as supprted by many clud service prviders, and supprts identity management because it wrks with existing prtcls such as SAML, OpenID cnnect etc. Based n these facts (at the time f writing), SCIM might get adpted as an industry standard fr identity prvisining. Sme f the challenges that enterprises cnsider fr identity management are: Hw t sync changes abut identities/access between enterprise -> clud, clud -> clud, clud -> enterprise Hw t de-prvisin identities and access acrss the enterprise and clud Hw t authr/update/manage access plicies in a manageable, scalable, lw-maintenance, lw-cst way. The current slutin fr many enterprises is the adptin f a hybrid IDM slutin that spans bth enterprise and clud. Access plicy management is a majr applicatin security challenge and ften requires maximum security autmatin as a slutin: Security plicy autmatin is particularly imprtant fr clud cmputing because clud users will demand supprt fr regulatry cmpliance plicy management frm clud prviders, but will at the same time judge the financial ROI by the same measures as they d fr clud cmputing in general, i.e., by hw much it cuts their up-frnt capital expenditure and their in-huse manual maintenance cst. 86 IDM - Identity Management 87 SPML - Service Prvisining Mark-up Language 88 SCIM - Simple Clud Identity Management 2011 CLOUD SECURITY ALLIANCE 117

119 Audit/Cmpliance Enterprises using clud services shuld answer three fundamental questins: 1. What clud resurces des a user have access t? 2. What clud resurces des a user actually access? 3. Which access plicy rules were used as a basis fr a decisin? With current clud deplyments, enterprise custmers have very limited visibility int clud service prviders fr audit data. An enterprise needs access t this data nt nly fr meeting the business driven cmpliance but als t meet industry regulatins and als deal with fraud disputes. Currently the IDM market is mving twards Identity and Access Gvernance (IAG) 89 market. Enterprises shuld als cnsider use f SIEM (Security Incident & Event Management) tls t crrelate clud applicatin access lg data and yur plicy data t generate plicy cmpliance reprts as well as use f auditable industry standards such as ISAE 3402/SSAE 16, HIPPA, DSS PCI, ISO27002, etc. General IdEA cnsideratins fr clud applicatin security are: Identity, Entitlement, and Access management shuld nt be an afterthught; rather, it shuld be integrated int an applicatin s SDLC starting with the requirements gathering. During the design phase cnsider hw t cntrl access t the applicatin using a Claims-based access whenever pssible. Cnsider using tls like SAPM (Shared Accunt Passwrd Management) fr managing highly privileged accunts within the applicatin. This allws fr segregatin f duties and least privilege. If the enterprise already has web access management tls, ensure that thse tls can be extended int a clud envirnment, i.e., by adding a SAML capability. Clud applicatins might need t leverage services ffered by service prviders such as lgging, database cnnectivity, etc. Mst service prviders expse these as web services r API. Access t these services culd be cntrlled by OAuth tkens. Thus clud applicatins shuld take int cnsideratin supprting varius tken types like OAuth, API keys, etc. Ensure that yu fllw an agile develpment prcess and that the applicatin is built int mdularized cmpnents. This allws the applicatin t leverage new emerging standards in the future like Mzilla s brwserid, Micrsft s U-Prve, and Kantara Initiative s UMA (User Managed Access). Be aware f the threats fr clud applicatins, which include: Spfing. Assuming the identity f anther user Tampering. Mdifying the data n transit 89 IAG - Identity and Access Gvernance 2011 CLOUD SECURITY ALLIANCE 118

120 Repudiatin. Denying the rigin f transactin (request r respnse) Infrmatin disclsure. Unauthrized disclsure f data Denial f Service. Affecting the availability Elevatin f Privilege. Assuming the rle r entitlement These threats culd be addressed by IdEA as fllws: Spfing. Authenticatin (strng authenticatin) Tampering. Digital Signature r Hash (As used in SAML assertins) Repudiatin. Digital signature (as used in SAML assertins), audit lgging Infrmatin disclsure. SSL, encryptin (Strictly nt IdEA specific) Denial f Service. Security Gateways (Web Services security gateways) Elevatin f Privilege. Authrizatin (OAuth) SECURITY GUIDANCE FOR CRITICAL AREAS OF Plicy Management Access plicy management (ften called authrizatin management when dne entitlement-centric) is the prcess f specifying and maintaining access plicies t resurces in access plicies, based n attributes including caller-related identities and related attributes (e.g. caller authenticatin), cntext attributes (e.g. envirnment/business/it related), and target-related attributes (e.g. thrttling r QS access plicies) 90. Entitlement management frms part f authrizatin and access management, which additinally includes authring and maintaining plicies fr attributes that are nt identity-related but are required (in additin t identity and its attributes) t make a meaningful access decisin. Entitlement/Authrizatin als takes attributes int accunt that are nt related t an identity, e.g.: General state f the IT landscape, business/business prcess, intercnnectin f IT systems r business prcesses, r envirnment, etc. (e.g. crisis level, emergency situatin) Other decisins made by ther entities (e.g. apprvals, prir decisins) Attributes related t the prtected target resurce (e.g. QS r thrttling plicies) Typically the authrizatin management, decisining, and enfrcement prcess is perfrmed in ne f three places: 1. Using a central/external Plicy Enfrcement pint / Plicy Server / Plicy-as-a-Service 2. Embedded as part f the Clud applicatin 3. Using an Identity-aaS r Persna-aaS (an entities Persna is its Identity with selected attributes). 90 Lang, U. Access Plicies fr Middleware, PhD thesis, University f Cambridge Cmputer Labratry, CLOUD SECURITY ALLIANCE 119

121 Clud Issues vs. Plicy Management Authrizatin/entitlement management fr clud faces several issues 91. Firstly, entitlement management fr clud has the specific issue that clud subscribers ften d nt have sufficient cntrl ver technical access plicy decisin-making and enfrcement in the clud infrastructure. Mst clud prviders tday d nt ffer subscriber-cnfigurable plicy enfrcement pints (e.g. based n the OASIS XACML standard), and clud prviders naturally cannt pre-cnfigure subscriber-specific plicies fr subscribers (because they are subscriberspecific). Secndly, an entitlement management cmplexity fr intercnnected cluds (mash-ups) is that access needs t be cntrlled fr the intercnnected clud mash-ups, and nt nly fr each individual clud nde. This means that plicies need t be authred fr service chains and delegatin acrss the intercnnected clud mash-up in mind Authrizatin Management Best Practice Establish whether an identity/entitlement-centric perspective is the best way fr yur rganizatin t authr and maintain access plicies; in many cases a prtected-resurce-centric perspective may be easier t authr and maintain because the gal is ften t prtect resurces, and plicies are ften distributed t the prtected end-systems fr autmatic plicy enfrcement (e.g. in entitlement/authrizatin management systems). In thse cases identity is merely ne attribute in an access plicy that is written with the gal f enfrcement at the prtected end-system in mind. Make sure that plicies are specified in a manageable frm. This includes specifying plicies that are generic, specified at a sufficiently high level f abstractin, and expressed clse t the understanding f the relevant rganizatin/business/humans. Mechanisms and tls are available t generate the detailed technical access plicy rules frm such a manageable frm (e.g. using mdel-driven security plicy autmatin) Architectures fr Interfacing t Access Plicy Prviders Plicy Decisin/Enfrcement Pints (PEP s/pdp s) using standard prtcls (e.g. XACML) r prprietary prtcls (e.g. direct web service r ther middleware calls) can access plicy servers (which cntain the rules fr an intercnnected clud mash-ups). The architecture is usually ne (server) t many (PDP/PEP s) if the plicy cvers a single trust dmain (e.g. an enterprise intranet). Hwever, in mre large-scale deplyments, there can be several federated plicy servers that service many different PDP/PEP s. Several access management prducts nw supprt authrizatin management rules (e.g. in XACML) that can be used t express entitlements fr identities. In additin, several authrizatin management prducts are available that can be used t authr authrizatin plicies frm a mre target-resurcecentric perspective Prvisining f Access Plicies In additin t identity + attribute prvisining, access plicies need t be prvisined (see abve Architectures fr Interfacing t Access Plicy Prviders ). Mrever, nn-identity attributes need t be prvisined, e.g., frm directry services r ther attribute surces. Bth need t be prvisined t the PDP/PEP s, and timeliness and crrectness play a critical rle. 91 Details: Lang U, Schreiner R, Analysis f recmmended clud security cntrls t validate OpenPMF, Infrmatin Security Technical Reprt (2011), di: /j.istr CLOUD SECURITY ALLIANCE 120

122 Managing Access Plicies fr Clud Making authring and maintaining access plicies manageable is a majr challenge; there are typically simply t many technical rules t manage, used plicy languages and attributes that d nt match the understanding f human administratrs, technical rules that need t be updated frequently t remain crrect after each time systems change (e.g. fr agile clud mash-ups), and it is hard t establish that the level f cnfidence/assurance f the technical plicy enfrcement matches the intent f the human administratr. As a cnsequence, it is critical t carefully plan the tls and prcesses t make this access plicy authring/updating prcess manageable thrugh autmatin. Current slutins include autmated appraches t turn high-level security plicies int (lw-level) technical access rules, including: Mdel-driven security 92, the tl-supprted prcess f mdeling security requirements at a high level f abstractin, and using ther infrmatin surces available abut the system (prduced by ther stakehlders). These inputs, which are expressed in Dmain Specific Languages (DSL), are then transfrmed int enfrceable security rules with as little human interventin as pssible. It als includes the run-time security management (e.g. entitlements / authrizatins), i.e., run-time enfrcement f the plicy n the prtected IT systems, dynamic plicy updates, and the mnitring f plicy vilatins. Clustering technical access rules int similar grups t reduce the cmplexity Visual attempts t make technical plicies easier t understand Authrizatin in the Clud Best Practice Carefully cnsider whether a prtected-resurce-centric perspective t authring access plicies may be mre suitable fr yur envirnment than an identity-centric perspective. Ensure manageability f access plicies, especially fr dynamically changing clud mash-ups. This includes cnsistency f plicy authring, plicy distributin, enfrcement, and update. Cnsider the use f autmated tls and appraches (e.g. mdel-driven security) t generate the technical access rules needed fr plicy enfrcement. Designate clear respnsibilities fr plicy management and plicy auditing. Ensure yur clud prvider ffers authrizatin management PEP s/pdp s that can be cnfigured with the subscriber-specific authrizatin plicy, and that yur plicy server can interface crrectly with the plicy selected. Cnsider the use f plicy-as-a-service as the plicy server if yu need a central plicy server fr a clud mashup. Current best practices fr selecting authrizatin services: The mst imprtant authrizatin management services feature is clud subscriber plicy manageability, because managing access plicies is the biggest challenge arund authrizatin. 92 NIST IR CLOUD SECURITY ALLIANCE 121

123 Services shuld allw fr as-autmatic-as-pssible technical plicy generatin (and update!) frm humanintuitive, generic security plicy requirements. If plitically viable fr yur rganizatin, and if available fr yu, plicy-as-a-service shuld be cnsidered as an ptin f utsurcing the plicy authring and updating. Mst likely this will be acceptable within cmmunity cluds where the plicy-as-a-service is ffered t a clsed cmmunity. Ensure services have an imprt and/r exprt functin int standards such as OASIS XACML. Ensure services can interface with PEP/PDP s installed in the clud infrastructure and with Plicy Mnitring Pints fr incident mnitring/auditing Applicatin Penetratin Testing fr the Clud A penetratin test invlves the prcess f evaluating the residual vulnerabilities present in the applicatin r system layer that can be ptentially explited by an external r internal hacker with malicius intent. The test wuld typically invlve active analysis f the surfaces f the applicatin r system as a "black bx" and attempts t identify typical vulnerabilities that can be prevalent as a result f bad prgramming r hardening practices. Open Web Applicatin Security Prject (OWASP) 93 in its OWASP Testing Guide V3.0 recmmends nine types f Active Security Testing categries as fllws: 1. Cnfiguratin Management Testing 2. Business Lgic Testing 3. Authenticatin Testing 4. Authrizatin testing 5. Sessin Management Testing 6. Data Validatin Testing 7. Denial f Service Testing 8. Web Services Testing 9. Ajax Testing (RIA Security Testing) The abve categries f Security testing will be equally applicable fr an applicatin that is ging t be deplyed n the Clud as the nature f Applicatin Vulnerabilities frm a technical perspective is nt ging t change. Hwever, depending upn the type f Clud Deplyment Mdel additinal threats vectrs (that wuld have nt cme int the equatin fr a nn-clud deplyment) culd be induced. An example f such a threat vectr in a SAAS deplyment wuld be induced by multi-tenancy when the same applicatin run time is being used t service multiple tenants and their segregated data. 93 OWASP - Open Web Applicatin Security Prject, CLOUD SECURITY ALLIANCE 122

124 Figure 3 Threat Vectr Inheritance Additinal classes f testing will need t be develped and included t address threats that arise as a result f the deplyment mdel f the Applicatin in the Clud. An illustratin f the same is prvided in the table belw. Table 2 Threat Vectr Inheritance CLOUD MODEL ON APPLICATION IS BEING DEPLOYED ADDITIONAL THREATS INDUCERS EXAMPLES OF THREATS TRADITIONAL SECURITY TESTING CATEGORIES STILL RELEVANT ADDITIONAL TESTING CATEGORIES SAAS Multi-tenancy at an Applicatin Level A different tenant using the same SAAS infrastructure gains access t anther tenants data thrugh the web layer vulnerabilities (a privilege escalatin) Cnfiguratin Management Testing Business Lgic Testing Authenticatin Testing Authrizatin testing Sessin Management Testing Data Validatin Testing Denial f Service Testing Multi-Tenancy Testing (an extensin f privilege escalatin) Web Services Testing Ajax Testing (RIA Security Testing) PAAS Multi-tenancy at a Platfrm Same as abve Same as abve Same as abve 2011 CLOUD SECURITY ALLIANCE 123

125 Level IAAS Multi-tenancy at an Infrastructure Level Deficiencies in virtualizatin security (imprper implementatin f VM zning, segregatin leading t inter VM attacks acrss multiple IAAS tenants) Traditinal Infrastructure Vulnerability Assessment (need t define this) Inter VM Security / Vulnerability Testing 10.5 Mnitring Applicatins in the Clud As with ther aspects f clud security, what and hw ne mnitrs a clud-based system varies with the type f clud under cnsideratin. What it means t mnitr applicatins in the clud and hw t mnitr different types f clud applicatins are explained in detail belw Applicatin Mnitring in the Clud: Give and Take Fr this dcument, we are limiting mnitring t fcus n applicatin security mnitring. In particular, the fllwing categries f metrics shuld be addressed: 1. Lg mnitring. It is nt just t archive lgs fr cmpliance purpses. Understand the ptential utput that culd be sent t these lgs, and mnitr fr actinable events. An applicatin lgging errrs is f zer use unless a prcess exists t detect and respnd t thse errrs. 2. Perfrmance mnitring. This plays a large factr in shared cmputing. A significant change in the perfrmance f ne applicatin culd be the symptm f anther custmer using mre than their fair share f a limited resurce (e.g., CPU, memry, SAN strage), r it culd be the symptm f malicius activity either with the applicatin being mnitred r with anther applicatin in the shared infrastructure. 3. Mnitring fr malicius use. This is a blend f auditing and mnitring required t be successful. The enterprise must understand what happens when a malicius user attempts t gain access, r use permissins that they d nt have. Audit lgs must lg failed (and successful) lgin attempts. D data-validatin functins lg anything? If an applicatin experiences a significant increase in traffic lad, is an alert created anywhere? 4. Mnitring fr cmprmise. Here the key is hw quickly and efficiently an rganizatin respnds t the cmprmise. Depending n the cmplexity f the applicatin, determining cmprmise might be relatively easy (e.g., User A is lgged in twice ) r may require mre effrt (e.g., develping heuristic algrithms t mnitr data usage). This is a gd example f an item that, when addressed earlier in the SDLC, can be easier t manage CLOUD SECURITY ALLIANCE 124

126 5. Mnitring fr plicy vilatins (especially access cntrl). It is als imprtant t mnitr and audit hw a Plicy Decisin Pint came t a decisin, i.e., which plicy rules were applied t make a specific access decisin. This is in line with a general plicy-driven mnitring apprach that avids the typical mnitring prblems f falsepsitives and incident verlad. These are sme f the key cncepts behind lg mnitring the take side f the equatin. Equally imprtant, the develper f an applicatin is respnsible fr the give side: His applicatin must prvide a slid lgging subsystem t allw the mnitring system t efficiently d its jb: 1. Easily parsable. Lgs shuld be written in a frmat that can be easily parsed by a separate system. A gd example wuld be using a well-knwn and accepted frmat such as XML. A bad example wuld be writing lg entries f nn-delineated, multi-line text utput. 2. Easily readable. Unless writing lgs in a binary frmat that will, withut a dubt, never be directly read by a human, a lg entry shuld be understandable by a persn with a technical backgrund, familiar with the applicatin. 3. Well dcumented. It is nt enugh t just write lgs t a file. Errr cdes need t be dcumented and shuld be unique. If a particular lg entry has a knwn path t reslutin, dcument the reslutin, r prvide a reference t it Mnitring Applicatins in Different Clud Types With an IAAS-based applicatin, mnitring the applicatin is almst nrmal, cmpared t legacy applicatins deplyed in nn-shared envirnments. The custmer needs t mnitr issues with the shared infrastructure r with attempted unauthrized access t an applicatin by a malicius c-tenant. Mnitring applicatins deplyed in platfrm-cluds requires additinal wrk. Unless the platfrm prvider als prvides a mnitring slutin capable f mnitring the deplyed applicatin, the custmer has tw chices: Either write additinal applicatin lgic t perfrm the mnitring tasks within the platfrm r send lgs t a remte mnitring system, be that the custmer s in-huse mnitring system, r a third party service. As SAAS-based applicatins prvide the least flexibility, it shuld nt cme as a surprise that mnitring the security f these types f applicatins is the mst difficult. Befre using a SAAS prduct, custmers must have a thrugh understanding f: Hw des the prvider mnitr their applicatins? What type f audit, lg, r alert infrmatin will the prvider send t the custmer? Des the custmer have the ability t select what infrmatin they will receive? Hw will the prvider transmit this infrmatin t the custmer? (Twitter? ? Custm API?) One final pint when cnsidering applicatin security mnitring in the clud: While prviders (r 3 rd party clud mnitring services) may have built a mnitring system t mnitr a custmer s applicatins, thse mnitring systems are mnitring hundreds, if nt thusands, f custmers. The prvider, as a business, wants this mnitring system t wrk well enugh. If the custmer has the resurces, running his/her wn mnitring system that mnitrs just his/her applicatins will almst always be mre respnsive and mre infrmative than that f a clud prvider CLOUD SECURITY ALLIANCE 125

127 10.6 Recmmendatins Security Assurance Recmmendatins Functinal and regulatry security and privacy requirements are defined that meet the needs f clud develpment and/r deplyment. A detailed assessment f the attack vectrs and risks in the clud envirnment are understd, and the mitigatins strategies are integrated int the requirements. An impact assessment fr all risks and attack vectrs is undertaken, and dcumented, tgether with the ptential fr lss r damage frm each scenari. Security and privacy requirements and effrts shuld be priritized n likelihd and impact Risk Analysis Recmmendatins Risk analysis f the applicatins fr security and privacy (cnfidentiality, integrity and availability) are undertaken, and threat mdels shuld be built and maintained. Risks frm the perspective f develpment and deplyment in the clud shuld be analyzed and related threat mdels maintained. Attack vectrs and impact analysis specific t clud architectures shuld be catalgued and maintained. Traceability between security assurance features and all identified risks / threats shuld be maintained Architecture Recmmendatins Secure sftware architecture framewrks shuld be develped and maintained. Clud cmputing architecture patterns that explicitly mitigate threats (fr example, frm Open Security Architecture 94 r TOGAF/SABSA 95 ) shuld be used. Reusable building blcks in the applicatin architecture are available fr mitigating cmmnly knwn security and breach scenaris. Clud-specific secure data architectures shuld be used t enhance the chsen security architectural framewrk, which will address clud specific issues and threats, such as: The mnitring f dynamic database servers Understanding where the database is exactly hsted at any pint in time CLOUD SECURITY ALLIANCE 126

128 Centrally lgging all activity, acrss disparate (ptentially glbal) systems t prvide a hlistic view f the applicatin and flag suspicius events Define where encryptin must be used (see Dmain 12) Prvide adequate segregatin f duties within the system, the data, and all privileged activities by third parties, capable f being mnitred by staff f the rganizatin that wns the data Penetratin Testing Applicatins n Clud Recmmendatins Carry ut regular Web Applicatin Penetratin Testing t check fr OWASP Tp 10 vulnerabilities Categrize vulnerabilities based n criticality / Impact and have a prcess fr remediatin Carry ut manual tests frm a multi-tenancy perspective t validate that privileges cannt be escalated r data segregated based n lack f sessin enfrcement. Fr applicatins being migrated t an IAAS r PAAS envirnment, a security assessment needs t be carried ut t ensure that the underlying security cntrls such as VM zning and segregatin, virtualizatin security, etc. has been effectively put in place and des nt pse a risk t the applicatin ecsystem CLOUD SECURITY ALLIANCE 127

129 REFERENCES [1] The Building Security In Maturity Mdel. [2] OpenSAMM Sftware Assurance Maturity Mdel. [3] DAVIS, NOOPUR. Secure Sftware Develpment Life Cycle Prcesses. Sftware Engineering Institute [4] SP-011: Clud Cmputing Pattern. pattern-clud-cmputing [5] KRUTZ, RONALD L. and VINES, RUSSEL DEAN Clud Security- A Cmprehensive Guide t Secure Clud Cmputing. Wiley Publishing, Inc., Indianaplis, IN. [6] SARNA, DAVID E.Y Implementing and Develping Clud Cmputing Applicatins. Auerbach Publicatins. [7] BELK, MARK, COLES, MATT, et al Fundamental Practices fr Secure Sftware Develpment: A Guide t the Mst Effective Secure Develpment Practices in Use Tday, 2nd EDITION. Sftware Assurance Frum fr Excellence in Cde. [8] RITTINGHOUSE, JOHN W. and RANSOME, JAMES F Clud Security Challenges in Clud Cmputing: Implementatin, Management, and Security. Auerbach Publicatins. [9] Guidelines n Security and Privacy in Public Clud Cmputing. Cmputer Security Divisin Infrmatin Technlgy Labratry Natinal Institute f Standards and Technlgy - Gaithersburg, MD [10] Hmmrphic Encryptin. Making Clud Cmputing Mre Secure. [11] Clud Data Prtectin. Best Practices CLOUD SECURITY ALLIANCE 128

130 DOMAIN 11 // ENCRYPTION AND KEY MANAGEMENT Fr a security prfessinal, it is bvius that if an rganizatin needs t stre data and desn t trust thse wh can access r use the data, then the data must be encrypted. Inside an n-premise data center where the rganizatin cntrls all assets, data is encrypted because sme regulatins say the data must be encrypted (PCI DSS fr example). In the clud, where there are multiple tenants and administratrs wrking fr smene else it wuld seem bvius that much mre data wuld need t be encrypted. If that is the case, hw d thse prcesses wrk and hw des the rganizatin manage their keys? Encrypting everything increases cmplexity. On the ther hand, is it even necessary t encrypt these vlumes f data if it causes business prcess cmplexity amngst ther issues? Is there anther way t reduce the need t encrypt data and subsequently manage the keys? This chapter lks at these issues. Overview. This dmain will address the fllwing tpics: Intrductin t Encryptin Alternative appraches t Encryptin Cryptgraphy in clud deplyments T encrypt r nt t encrypt? That is the questin. If yes, hw d I manage the keys? If n, are risks t high? Encryptin in Clud Databases Key management in the clud Strage and safe-guard f keys 11.1 Intrductin t Encryptin Data classified as cnfidential fr reasns f regulatry cmpliance r crprate secrecy must be prtected. As cnfidential infrmatin that is currently managed within internal systems increasingly mves t the clud, it must be prtected with the same diligence. Mving data t the clud des nt remve any requirements fr cnfidentiality and data prtectin. The lss f cntrl f data utside the secured crprate perimeter (de-perimeterizatin) increases the cmplexity f prtecting data and increases the risk f cmprmise. There are a number f factrs t cnsider regarding data encryptin in the clud, which include: Prtecting data thrugh encryptin as it mves t the clud requires mre than just ensuring that a secure transfer channel (i.e. TLS) is used. Encrypting the transfer f data t the clud des nt ensure the data is prtected in the clud. Once data arrives in the clud, it shuld remain prtected bth at rest and in use. Fr unstructured files that must be prtected when stred r shared in the clud use data-centric encryptin, r encryptin embedded int the file frmat whenever practical t apply prtectin directly t files CLOUD SECURITY ALLIANCE 129

131 Understand hw all encryptin / decryptin keys will be managed fr the entire lifecycle f the data. Whenever pssible avid any reliance n clud prviders t prtect and apprpriately use the keys that prtect yur critical infrmatin. Avid pprtunities fr lapses in the emplyee safeguards f thers, r f reginal laws that may prvide undesired, but mandated access t yur encrypted files. If nly yu have the keys, nly yu can access yur files. D nt frget t prtect files that are ften verlked, but which frequently include sensitive infrmatin. Lg files and metadata can be avenues fr data leakage. Encrypt using sufficiently durable encryptin strengths (such as AES-256) that cmply with the same crprate and regulatry mandates used fr encrypting internally maintained files. Use pen, validated frmats and avid prprietary encryptin frmats wherever pssible Alternative Appraches t Encryptin There are gd reasns t lk at alternate appraches t encrypting data in the clud. Fr many rganizatins sending data int the clud is equivalent t transferring custdial relatinship. Fr thse rganizatins that have issues with sending unsecured data utside their rganizatin there are alternatives: Tkenizatin. This is where public clud service can be integrated/paired with a private clud that stres sensitive data. The data sent t the public clud is altered and wuld cntain a reference t the data residing in the private clud. Data Annymizatin. This is where (fr example) Persnally Identifiable Infrmatin (PII) 96 and Sensitive Persnal Infrmatin (SPI) 97 are stripped befre prcessing. Utilizing clud database cntrls. This is where the access cntrls built int the database are deemed t prvide adequate levels f segregatin. As a rule, gd data management practices are essential befre mving data int the clud, t understand whether all r just sme f the data need t be encrypted, prtected by an alternative methd, r nt prtected at all. When evaluating what t prtect thrugh encryptin f ther alternative methds there are risks f data sharing 98 that can be brken dwn int tw primary categries: disclsure and misuse, under the fllwing areas: Accidental public disclsure. Making infrmatin r data readily available t the general public via publicatin r psting n the web. Accidental r malicius disclsure. The act f making infrmatin r data available t a third party(s) as a result f inadequate data prtectin. 96 PII - Persnally Identifiable Infrmatin 97 SPI - Sensitive Persnal Infrmatin CLOUD SECURITY ALLIANCE 130

132 Cmpelled disclsure t third parties. The bligatins f having t respnd t subpenas requesting data disclsure in lawsuits. Gvernment disclsure. The release f data t gvernment entities, either by law, r by curt rder (such as the Patrit Act). Misuse f user r netwrk prfiles. The ability t analyze and data mine t derive sensitive infrmatin frm seemingly benign traffic data, and thereby reveal user behavirs, assciatins, preferences r interests. Inference misuse. Being able t synthesize first-rder r secnd-rder identifiers t draw inferences abut a persn's behavir r identity. Re-identificatin and de-annymizing misuse. Having access t enugh annymized infrmatin t be able t infer the riginal subject Cryptgraphy in Clud Deplyments There are tw cmplementary cncepts used in the encryptin sectin, they are: Cntent Aware Encryptin. Used in Data Leak Preventin, cntent aware sftware understands a data type r frmat and encrypts based upn plicy settings. Fr example a credit card number is encrypted in an being sent t law enfrcement. Frmat Preserving Encryptin. Encryptin that preserves frmat is a result that encrypts a message and prduces a result like the input message. Fr example, a 16-digit credit card number is a 16-digit number after encryptin, a telephne number wuld lk like a telephne number, and an English wrd wuld lk like an English wrd. The ability t encrypt frm the enterprise t the clud withut user interventin is t the preferred way t make data safe. Cntent aware sftware can be leveraged fr public clud encryptin if the sftware can be cnfigured t be prtcl aware as well and encrypt fields in a REST http transactin t a public clud applicatin. The Data Leak Preventin (DLP) 99 use case tday is met by prducts that can enfrce data prtectin leaving the enterprise, usually by , and encrypt data befre the transactin leaves the enterprise. This principle can be used in clud data prtectin; hwever, the DLP prduct may generate alerts. A cntent aware service wuld need t detect, encrypt, and lg but nt alert. Frmat preserving encryptin takes cntent aware a step further by being sensitive t the data needing encryptin and maintaining the data frmat and type. Fr example, with cnventinal encryptin, a credit card being encrypted wuld render a cipher-text 100 that wuld n lnger be a 16-digit number. Frmat preserving encryptin wuld generate a cipher text value that is 16 digits in additin t being encrypted. By als preserving the data type and frmat the service prviding encryptin can then easily change values in line ver a wide variety f prtcls. The key challenge t frmat preserving encryptin is in encrypting large clear text values such 99 Data Leak Preventin (DLP) prducts have an enfrcement mde that detects data leaving a secured device r the enterprise and encrypts it. 100 Cipher text - The result f an encryptin peratin. The input is knwn as clear text CLOUD SECURITY ALLIANCE 131

133 as an stred in the clud. Bulk scale encryptin is nrmally hw text values are encrypted using blck ciphers 101. In the frmat preserving case, each wrd wuld be encrypted int a character string f the same length, which takes time. The result, hwever, wuld be cipher-text data values that can be stred in fields f the same data-type as the riginal plain text. Encryptin in clud applicatins pses sme issues fr business applicatins that the applicatin architecture needs t address. These are: If data in the applicatin is needed t search fr recrds r bjects, then an encrypted primary key 102 wuld make that difficult. If the clud applicatin set cntains batch jbs r ther types f prcesses that wrk n sensitive data, particularly PII and SPI data, and thse prcesses are mved t the clud, that situatin will cmplicate key management. An applicatin that needs t find recrds r bjects in a database may chse t develp anther way t stre a unique value such as tkenizatin. Tkens are ften used in credit card envirnments t ensure the credit card number is minimally accessed in applicatins. A unique tken generated frm the value can be used t develp a new primary key that the applicatin can use withut expsing sensitive data in a public clud. As will be discussed in sectin 11.4 belw, where pssible, keys shuld nt be stred in the clud and must be maintained by the enterprise r a trusted key management service prvider. Prcesses that need t perate n clear text data and run in the clud with ther business applicatins and data must have access t keys r a service in rder t perfrm their functins. See sectin 11.4 fr mre details n key management in the clud Encryptin in Clud Databases The first thing t cnsider is whether it is necessary t encrypt the data. All databases prvide the ability t restrict access t data. If prperly implemented, that may be enugh t prtect cnfidentiality. Other reasns that may require the encryptin t prtect data stred in the database are: T hide it frm thse with privileged access t the database (Database Administratrs (DBA s) 103, fr example) T cmply with legal statutes (such as Califrnia's SB1386 law) T stre it in a schema fr which the data wner cannt cntrl the accunt credentials accessing the data (using shared accunts, fr example) When using a clud database and particularly SaaS slutin emplying a database, the database ability t functin crrectly may be cmprmised unless it can perate n the encrypted data, necessitating the database r clud applicatin t have access t the keys. 101 Ciphers - Algrithm based sftware/hardware that perfrm encryptin/decryptin and signing/verifying 102 Primary key - A database clumn/field/attribute that is used t uniquely identify recrds in a database 103 DBA - Database Administratr 2011 CLOUD SECURITY ALLIANCE 132

134 Data encryptin cmes at the price f cmplexity and perfrmance, and there are effective alternatives t encryptin: Use bject security. Use SQL grant and revke statements t restrict which accunts can access the data. The accunts t which yu grant access must be cntrlled t ensure that yu are nly allwing access t authrized users. Stre a secure hash. Rather than string the data directly, stre a hash f the data. This allws yur prgram t prve that the hlder has the crrect value withut actually string it Key Management One f the mre difficult prcesses in public clud cmputing is key management. The multi-tenant mdel f public clud slutins causes key management issues fr prcesses running there. The easiest use cases are thse that have applicatins running in the public clud and keys that encrypt data ging t the public clud frm the enterprise are used within the enterprise nly. As described in sectin ne, there are encryptin engines that can encrypt data n the way ut and decrypt data n the way back in. An applicatin using cryptgraphic keys gets cmplicated when ther prcesses, such as batch prcesses, need access t keys t decrypt data and thse prcesses reside in the public clud. Enterprise users f encryptin need t have keys f their wn s that a single shared key is nt used acrss the enterprise. The easiest way t accmplish such specific keys is a cryptgraphic engine fr each user r entity 104 t have keys assigned (and managed) based n the entities identity. In this way, anything that is encrypted specifically fr an entity is maintained fr that entity. If an entity needs t share access t data in a grup setting then grup level keys can be assciated with the applicatin that maintains grup access, and entities within that grup can share the keys. The keys shuld be maintained within the enterprise as discussed earlier in this sectin. Where data is stred in a public clud envirnment, there are prblems when exiting that envirnment t be able t prve that all data (especially PII r SPI data, r data subject t regulatry assurance regimes) has been deleted frm the public clud envirnment, including all ther media, such as back-up tapes. Maintaining lcal key management allws such assurance by revking (r just deleting/lsing) the key frm the key management system, thus assuring that any data remaining in the public clud cannt be decrypted Strage and Safe-Guarding f Keys Encrypting data has little value if bth prviders as well as users f clud services d nt vigrusly enfrce the prcesses arund key management. On the prvider side, a lack f SOD 105 (Segregatin f Duties) arund access t key servers and servers having encrypted data shuld be a cause fr cncern, as well as DBA s having access t individual keys fr databases, r the architecture f the database service reliant n a single key. 104 Entity - Fr the purpse f identity, culd be a user, cde, a device, an rganizatin r agent 105 SOD - Segregatin f Duties 2011 CLOUD SECURITY ALLIANCE 133

135 Cntrls arund prtecting the keys themselves, by using KEK 106 (Key Encrypting Keys) and generatin f encryptin keys in-memry, and nly string the encrypted key f key servers are all valid architectural slutins that shuld be cnsidered when architecting any slutin. Keys managed n the client side that prtect keys n devices that are nt themselves secure (such as mbile devices) r devices which d nt have the same level f cntrls as the encrypting system itself shuld be a cause fr cncern Recmmendatins General Recmmendatins Use best practice key management practices when using any frm f encryptin/decryptin prduct. Use ff-the-shelf technlgy where pssible t get the best practices frm a credible surce. Use best practice key management practices and btain technlgy and prducts fr encryptin, decryptin, signing, and verifying frm credible surces. It is highly recmmended that rganizatins maintain their wn keys r use a trusted cryptgraphic service frm a surce that currently maintains such a service. If an rganizatin needs t run analytics r ther prcesses using data stred in the clud then the rganizatin shuld develp n tp f a platfrm such as Hadp and have that data derived frm the clud surce. Such develpment platfrms, including Hadp, have their wn set f security issues but thse are beynd the scpe f this chapter. Key scping can be maintained at the individual r grup level. Grup access can be managed with ff-the-shelf technlgy such as DRM systems and ther sftware running n the desktp/laptp that encrypts disks, flders, and messages. Recmmendatins - Encryptin within Databases Use standard algrithms. D nt invent/use prprietary scrambling techniques. Prprietary encryptin algrithms are unprven and easily brken. Avid ld insecure encryptin standards such as Data Encryptin Standard (DES) 107. Use bject security. Yu shuld still use basic bject security (SQL grant and revke statements) t prevent access t even the encrypted data. D nt encrypt primary keys r indexed clumns. If yu encrypt a primary key, yu will have t encrypt all referencing freign keys. If yu encrypt an indexed clumn, yu may end up with slw queries when trying t use the encrypted value. Use a clumnar apprach t encryptin (since big data system uses this). 106 KEK - Key Encrypting Keys 107 DES - Data Encryptin Standard 2011 CLOUD SECURITY ALLIANCE 134

136 11.6 Requirements In rder t maintain best practices and pass audits the rganizatin shuld manage their keys in the custdy f their wn enterprise r that f a credible service frm a cryptgraphic service prvider. Keys used in existing encryptin technlgy such as DRM and disk encryptin prducts shuld be managed by central, internal t the enterprise, key strage technlgy. Hardware Security Mdules (HSM) shuld be used t stre keys as well as prcess cryptgraphic peratins such as encryptin/decryptin, signing and verifying. Enterprise users shuld g thrugh a registratin prcess t enable cryptgraphic peratins and ther prcesses in the enterprise, such as Cntent Aware r Frmat Preserving systems can access encryptin/decryptin keys as needed. Deply technlgy integrated int crprate systems based n the identity f all cmpnents in the prcessing chain t make entitlement decisins. Manage keys used by the cryptgraphic prcesses using binding cryptgraphic peratins. Use existing systems such as E-DRM 108 r DLP if pssible. Binding cryptgraphic peratins and key management t crprate identity systems will prvide the rganizatin with the mst flexible integratin and uses technlgy that the rganizatin already knws wrks and has been audited and r reviewed. 108 E-DRM - Enterprise Digital Rights Management. A prcess that prtects cntent such as internal crprate cmmunicatins r cpyrighted material CLOUD SECURITY ALLIANCE 135

137 DOMAIN 12 // IDENTITY, ENTITLEMENT, & ACCESS MANAGEMENT SECURITY GUIDANCE FOR CRITICAL AREAS OF The cncepts behind Identity, Entitlement, and Access Management used in traditinal cmputing require fundamental changes in thinking when implementing a clud envirnment, particularly splitting it int three discrete functins, Identity, Entitlement, and Authrizatin/Access Management (IdEA). Fr mst rganizatins, implementing a traditinal applicatin means implementing a server, pssibly in a DMZ 109, and in mst cases tied int a Directry Service (DS) 110 (such as Micrsft s Active Directry,Nvell s edirectry r Open LDAP) fr user authenticatin. In sme cases it means implementing an applicatin r using a web-delivered service using its wn stand-alne authenticatin system, much t the annyance f the users wh then have t remember sets f credentials (r wrse, reuse credentials frm ther, perhaps mre trusted, dmains). In cntrast, a well implemented clud service r applicatin-identity shuld be cnsumed frm a variety f external surces tgether alng with the assciated attributes (remembering that an identity applies nt nly t Users 111, but als Devices, Cde 112, Organizatins and Agents which all have identity and attributes). Leveraging all the multiple identities and attributes invlved in a transactin enables the clud system t make better hlistic risk-based decisins (defined by the entitlement prcess 113 and implemented by the authrizatin & access management cmpnents) abut granular access t the system, prcesses, and data within the clud system / applicatin. This prcess f using multiple surces f Identity and their related attributes is critical when a clud applicatin is likely t be Internet-facing, and is als likely t be ne f the main hurdles fr rganizatins wanting t use true clud services and instead pt t implement virtualizatin technlgies in their wn DMZ cnnected t their wn internal DS. This de-perimeterized 114 apprach t identity, entitlement, and access management prvides a mre flexible and secure apprach but als can be implemented equally well inside the crprate bundary (r perimeter). Overview. The fllwing sectins cver the key aspects f Identity, Entitlement, and Access Management in a clud envirnment: Intrductin t Identity in a clud envirnment Identity architecture fr the Clud Identity Federatin 109 DMZ - DeMilitarized Zne 110 DS r "Directry Service" is used thrugh this sectin as an abbreviatin fr a generic crprate directry service, used fr username and passwrd lgin. 111 Typically humans; fr a wider definitin and expansin refer t Cde includes all frms f cde, up t including applicatins and self-prtecting data. 113 "Entitlement" is the prcess f mapping privileges (e.g., access t an applicatin r its data) t identities and the related attributes. 114 De-perimterizatin is a term cined by the Jerich Frum ( CLOUD SECURITY ALLIANCE 136

138 Prvisining and gvernance f Identity and Attributes Authrizatin and Access Management Architectures fr interfacing t Identity and Attribute prviders Level f trust with Identity and Attributes Prvisining f accunts n clud systems Applicatin Design fr Identity Identity and Data Prtectin 12.1 Terminlgy Used in this Dcument The language used arund identity is cnfused, with sme terms having diametrically ppsite means t different peple. T avid cnfusin while reading this dmain, sme f the identity terms used within this dmain are defined belw: Identity. The means by which an Entity can cnsistently and cmprehensively be identified as unique. Identifier. The means by which an Identity can cryptgraphically asserted, usually using public-key technlgy. Entity. Discrete types that will have Identity; these are t Users, Devices, Cde, Organizatins and Agents. Entitlement. The prcess f mapping privileges (e.g., access t an applicatin r its data) t Identities and the related Attributes. Reduced Sign-n (RSO). The use f an accunt and/r credential synchrnizatin tl t minimize the number f credentials (usually username and passwrd) a user has t remember; mst f these slutins result in sme frm f security cmprmise. Single Sign On (SSO). The ability t pass Identity and Attributes t a clud service, securely, using secure standards such as SAML 115 and OAuth 116. Federatin. The cnnectin f ne Identity repsitry t anther. Persna. Identity plus the particular Attributes that prvide cntext t the envirnment the Entity is perating within. A Persna may be an aggregatin f an individual Identity tgether with an Organizatinal Identity and Organizatin Attributes (e.g. a crprate Persna, Fred Smith as CEO f ACME Crp., r a Persnal Cmputer belnging t ACME Crp.). Attributes. Facets f an Identity 115 SAML- Security Assertin Markup Language, an XML-based OASIS pen standard fr exchanging authenticatin and authrizatin data between security dmains 116 OAuth-Open Authrizatin, an pen standard fr authrizatin, allwing users t share their private resurces with tkens instead f credentials 2011 CLOUD SECURITY ALLIANCE 137

139 12.2 Intrductin t Identity in a Clud Envirnment SECURITY GUIDANCE FOR CRITICAL AREAS OF An identity ec-system faces scaling prblems (think f the mve frm a small village where everyne knws everyne else, t a large twn r city). As the industry expands identity systems frm single cmputers int glbal enterprises and then int clud deplyment mdels, the ability t identify all the entities invlved in a transactin becme significantly mre difficult. Hwever, with clud, the use f Identity fr all Entities in the transactin value-chain, and the mve t risk-based decisins, cannt nly mitigate the risk but als ptentially imprve security. The fllwing key pints need t be cnsidered when implementing a clud based slutin that needs t use identity infrmatin: The strength with which an Identity can be asserted will feed int the risk calculatin when interacting with that Identity (examples include Annymus; self-assert; validated by a knwn reputable rganizatin with a strng assertin f rganizatinal Identity). The Attributes f a Persna, like Identity, will have a strength with which an Attribute can be asserted that feed int the risk calculatin when interacting with that Persna. Assertin strength ranges frm self-asserted t validated by a knwn reputable rganizatin (with a strng assertin f rganizatinal Identity). Identity and Attributes will need t be cnsumed frm multiple surces, thus clud slutins / architectures will need the ability t cnsume multiple disparate surces f Identity and Attributes. There will be instances when a transient Identity is sufficient (enugh infrmatin abut an Entity t deem them unique). There will be instances where pseud-annymity is desirable (such as vting) Identity Architecture fr the Clud The mve frm a traditinal architecture f a perimeterized rganizatin with traditinal server based applicatins in internal cmputer centers affrds little flexibility t an rganizatin. The mve t clud-based architectures allws greater flexibility, whether deplyed internally within the rganizatinal bundaries (a private clud) r external public cluds (SaaS, PaaS r IaaS). The table n the fllwing page shws hw identity needs t vary between traditinal implementatin and clud implementatin, dependent n the type f clud architecture implemented CLOUD SECURITY ALLIANCE 138

140 Table 1 Identity Architecture Assertins SECURITY GUIDANCE FOR CRITICAL AREAS OF ARCHITECTURE TYPE TRADITIONAL ARCHITECTURE CLOUD ARCHITECTURE Internal / Perimeterized Cnnected t the internal DS Identities must be maintained within the DS t be used by the applicatin, ptentially using reduced sign-n slutins. Ability t accept multiple surces f Identity and Attributes. Internal / De-perimeterized Need t tightly cntrl and cnnect t rganizatinal services using VPN tunnels at back end. Nt a recmmended architecture. Use assertins t prvide Identity and Attributes t access clud services. External / Perimeterized External hsting means extending perimeter t the prvider f the server. Identity is extended int an envirnment the cnsumer des nt manage, ften putting a replica f the DS int that envirnment fr perfrmance. Use assertins t prvide Identity and Attributes t access clud services. External / De-perimeterized External hsting means extending internal Identity int a freign envirnment, but a back-end leaded line r VPN. Identity is extended int an envirnment the cnsumer des nt wn r manage, ften replicating DS int that envirnment fr perfrmance Use assertins t prvide Identity and Attributes t access clud services. Whereas in a traditinal IAM 117 architecture, ften all the cmpnents are stand-alne as part f a single server, a clud architecture is ptentially mre cmplex taking Identity and Attributes frm a number f surces and making authrizatin / access management decisins via a set f Entitlement Rules defined by the Entitlement Prcess. 117 IAM-Identity and Access Management 2011 CLOUD SECURITY ALLIANCE 139

141 In Figure 1, Identity and Attributes are surced frm (ptentially) multiple surces and feed int an authrizatin/access management layer that translates the entitlement rules int access. Identity Surce #1 Access Management Identity Surce #2 Attribute Surce #1 Identity & Attribute Surce #1 Authrizatin Entitlement Rules Netwrk Access System Access Applicatin Access Prcess Access Data Access Entitlement Prcess Figure 1: Generic Identity, Entitlement & Access Management System Access Management shuld (depending n the business / security requirements, and the type f clud mdel, IaaS, PaaS r SaaS being deplyed) gvern access t the; Netwrk layer. Withut meeting the entitlement rules it may nt even be pssible t see (i.e. Ping r rute) t the clud system. The entitlement rules may als direct access t particular interfaces. System layer. The entitlement rules may define the prtcls that are permitted t access and mdify systems, such as terminal server vs. web. Applicatin layer. The entitlement rules may map Identity and/r Attributes t functinality prvided by a specific applicatin, such a being presented with a reduced set f menus r ptins. Prcess layer. The entitlement rules can be used t define the prcesses (r functins) that can be run within an applicatin. Entitlement may als define that enhanced functins (such as transferring mney ut f the ecsystem) need additinal verificatin (which may be btained directly r derived in the backgrund). Data layer. The entitlement rules may limit access t areas f the data and file structure r even individual files r fields within files (e.g., in a database). At a mre advanced level, entitlement culd be used t aut-redact dcuments, such that tw users accessing identical dcuments wuld view different cntent (e.g., cnstructing a specific dynamic view f a database table). The entitlement prcess starts with the custmer t turn business requirements and security requirements int a set f entitlement rules. This prcess will define the identities and Attributes required t be able t evaluate the rules. These rules in turn drive the authrizatin/ access system Identity Federatin Cnceptually speaking, federatin is the intercnnectin f disparate Directries Services. Sme rganizatins pt fr a federatin gateway, (a Bridge r Federatin Hub ) in rder t externalize their federatin implementatin, where the 2011 CLOUD SECURITY ALLIANCE 140

142 federatin and the rules by which Identity is managed within that bridge is gverned by a set f rules, usually a legal cntract, thus allwing ther partners in this bridge a defined level f trust in identities nt directly issued by themselves. Technlgically speaking, federatin is the use f SAML t ffer prtability t disparate and independent security dmains with sme rganizatins extending their DS envirnment via a gateway prduct that will handle SAML assertins. Other rganizatins will cnsume native SAML assertins frm an identity service. In bth these types f federatin architectures, it is essential t understand the prvenance f the Identity and Attributes that are being asserted. Federatin standards are used widely fr SaaS deplyment mdels fr bth identity federatin and access cntrl. There are n similar standards fr PaaS r IaaS deplyment mdels. Clud Cnsumers leveraging IaaS deplyment mdels shuld take int cnsideratin hw they manage the lifecycle f identities (shared accunts, named accunts, privileged accunts etc.). Enterprises that leverage the Privileged Identity Management (PIM) tls fr Super User Management (SUPM) and Shared Accunt Passwrd Management(SAPM) shuld investigate extending these tls t supprt clud deplyments. Enterprise r Clud Cnsumers must have a well-defined plicy fr HPA (Highly Privileged Access) Prvisining and Gvernance f Identity and Attributes When talking abut prvisining, typically we think abut user prvisining, but t make rich, risk-based decisins, the clud system / applicatin needs Identity and Attributes frm all entities invlved in the transactin and ptentially ther Attributes frm ther systems / prcesses. Sme examples f Identity and Attributes are as fllws (nt an exhaustive list): User Assertins: User Identifier (The public part f a Public/Private key pair) User Name (User Name shuld be just anther Attribute f Identity) Credential strength/trust Lcatin Assertins; IP-Address, Ge-lcatin, GPS, Cellular Service Lcatin Organizatin Identity (Identifier crypt) and Organizatin Assertins Device Identity (Identifier crypt) and Device Assertins; Functinality Required, Functinality Offered, Sandbx capability, Secure cntainer, Cleanliness f device Cde Identity (Identifier crypt) and Cde Assertins Training recrd / cmpliance, etc. The master surce f Identity and the Attributes f an Identity (which may be frm a different surce) need t be identified in the design f the entitlement prcess CLOUD SECURITY ALLIANCE 141

143 As a rule, the clud service r applicatin itself shuld avid being the master surce fr Identity (exceptins may be a clud based HR service, r a clud Identity-as-a-Service ffering). Hwever, during the transitin t clud services (nt best practice) the clud service / applicatin may need t hld identities r perate a mixed-mde mdel. All Attributes shuld be linked t an Identity, as withut the assciated Identifier and level f trust with that Identifier the Attributes have n prvenance. While this may at first sight be cunterintuitive, the strength in the entitlement prcess lies in defining thse Attributes necessary t make the rules wrk the way the business requires them t and then identifying the authritative surce (r as clse as pssible) t prvide thse Attributes (with the related Entity Identifier). Examples wuld include: Security threat level: Organizatinal, Gvernment, r Outsurced prvider Identity Apprvals r prir decisins made by ther Entities: Entity Identity QS r thrttling plicies related t a prtected target resurce; System Identity 12.6 The Entitlement Prcess The entitlement prcess starts with the custmer t turn business requirements and security requirements int a set f rules that will gvern authrizatin and access t the varius aspects f the clud system. This prcess will then define the identities and Attributes that are required t prperly evaluate the entitled rules. The entitlement prcess and the derived rules shuld nt nly drive the authrizatin and access management f a clud system, they can als specify a degree f negtiatin/entitlement at all layers f the clud infrastructure, e.g., t allw prtcls and interfaces at the netwrk and/r system layer. The entitlement prcess shuld be embedded int any business requirements dcument and als the technical requirements dcument; it shuld als feature as an integral part f the clud vendr s prvisining / custmer nbarding prcess. The entitlement prcess des nt stp nce the clud service is up and running, but the entitlement rules and the subsequent rules that drive authrizatin and access must be the subject f regular review. The entitlement prcess must then be audited by the business system-wner against the business requirement. Any audit must include the threat and risk assessment and any regulatry requirements. Current slutins include autmated appraches t turn high-level security plicies int (lw-level) technical access rules, including: Mdel-driven security 118, a tl-supprted prcess f mdeling security requirements at a high level f abstractin and using ther infrmatin surces available abut the system (prduced by ther stakehlders) Clustering technical access rules int similar grups t reduce the cmplexity Visual attempts t make technical plicies easier t understand The entitlement prcess shuld define thse Entities, Identities, and Attributes that are required t make meaningful authrizatin and access decisins. It shuld als define thse Attributes that are fixed within the prcess, r thse that CLOUD SECURITY ALLIANCE 142

144 have a tempral (change ver time) aspect t them, and therefre either the time interval at which they must be revalidated, r the trigger within the prcess, will frce revalidatin. Where Identity and Attributes that need t be surced frm utside the business s cntrl are defined in the entitlement prcess, the Organizatinal Identity (Identifier) f that prvider (Entity) must be n-barded as well, and thus (at sme pint in time) ff-barded. Typically the entitlement rules are interpreted in ne f three places: 1. Using a central/external Plicy Enfrcement pint / Plicy Server / Plicy-as-a-Service 2. Embedded as part f the Clud applicatin 3. Using an Identity-aaS (IDaaS) 12.7 Authrizatin and Access Management Authrizatin and Access Management is the prcess by which the entitlement rules are translated (via the Authrizatin layer) int Access Management rules. In mst clud based systems, the Authrizatin layer is likely t be a Plicy Decisin Pint (PDP) 119 r the pint that evaluates and issues authrizatin decisins, and the Access Management layer, the Plicy Enfrcement Pint (PEP) 120, the pint that enfrces the PDP's decisin. The PDP and PEP will be part f an authrizatin ec-system that uses XACML 121 (extensible Access Cntrl Markup Language) as a declarative access cntrl plicy language implemented in XML. A PEP culd be as simple as an IF (cnditinal) statement in the clud applicatin r as advanced as an agent running n an applicatin server r a filter in an XML-gateway that intercepts access requests, gathers necessary data (Attributes) t be able t evaluate the Entitlement Rules, and then makes and implements these decisins. This is nt t mandate the use f XACML, PDP s, and PEP s in a clud envirnment, as the functinality culd ptentially be implemented in ther ways (prbably in a clsed r prprietary ec-system). PDP s can be implemented utside f the clud envirnment, pssibly within the custmer s envirnment. This can ptentially have a number f advantages such as interfacing t an internal DS and/r the ability t integrate lgs abut the decisin made directly int an internal lgging system Architectures fr Interfacing t Identity and Attribute Prviders There are three basic architectures fr interfacing t Identity and Attribute prviders: 119 PDP - Plicy Decisin Pint 120 PEP - Plicy Enfrcement Pint 121 XACML - extensible Access Cntrl Markup Language 2011 CLOUD SECURITY ALLIANCE 143

145 1. A hub-and-spke mdel where Identity and Attributes are centrally managed (crdinated) by the hub, which then interacts with the clud service(s) r clud applicatin(s) 2. The free-frm mdel where the clud service and/r applicatin can be cnfigured t accept Identities and Attributes frm multiple surces 3. The hybrid slutin, where the cmpnents are distributed, ptentially using ther clud services. Each mdel has its merits, and the chice will be based n the number f factrs, including: Where the custmers fr the service have their identity The capability f the clud service chsen The capability f the enterprise t prvide assertin-based Identity and Attributes Hub and Spke Mdel The hub and spke apprach typically allws the clud service t interface directly with the rganizatin fr its Identity and Attribute infrmatin, ideally in the frm f standards-based assertin prtcls, such as OAuth & SAML. The rganizatin s internal systems are respnsible fr keeping track f users, ther entities and the Attributes. This is mst like a traditinal IAM system, and thus prbably the easiest t transitin t fr clud slutins being implemented by rganizatins, as mst DS r LDAP systems can have a SAML capability blted-n. It is likely in this mdel that the entitlement prcess might als be handled within the rganizatin thrugh the use f a Plicy Enfrcement Pint and Plicy Server and cmmunicated via XACML (thugh XACML isn t that widely used fr this yet). Figure 2 illustrates the hub-and-spke apprach. One benefit f this apprach is that maintaining a Plicy Enfrcement Pint within the rganizatin allws the integratin f audit lgs t be maintained within the rganizatin and even crrelated with ther disparate audit trails (utside f the clud envirnment, r frm ther clud envirnments) t get the cmplete picture required. Examples f this include Segregatin f Duties analysis and satisfactin f regulatry requirements. The hub-and-spke apprach is likely t be used when a high degree f cntrl is required ver all users with a central enrllment prcess. This is mre likely in rganizatins that are subject t heavy regulatin. The hub-and-spke shuld als lessen the dependency n the Identity/Attribute prviders, as Attributes are ften stred (duplicated) within the central hub. This is als the mdel used when an rganizatin subscribes t a Bridge r Identity Hub. Identity / Attribute Prviders Central Brker Prxy r Repsitry Service Prviders Figure 2 Hub & Spke Mdel 2011 CLOUD SECURITY ALLIANCE 144

146 Free Frm Mdel In the free-frm mdel, the clud service / applicatin is respnsible fr maintaining the surces f Identity and Attributes. This slutin is mre suited fr a public facing slutin r a slutin with a large number f disparate partners. The free frm apprach has the advantage that it is easier t setup, at least fr current federatin prtcls (such as SAML) but relies n a gd implementatin f the entitlement mdel t allw it t scale t a large amunt f users. Identity / Attribute Prviders Service Prviders One apprach is t setup a pint-t-pint federated trust relatinship Figure 3 Free Frm Mdel (using prtcls such as SAML and OAuth) between the service and Attribute/Identity prviders, but this apprach needs an efficient prcess t n-bard and ff-bard thse prviders. The free-frm mdel prvides challenges t prvisining users, as the envirnment f new entities cnnecting is likely t be mre ad-hc. Again, careful design f the Entitlement Prcess will help t alleviate this prblem. Figure 3 abve illustrates the pint-t-pint apprach Hybrid Mdel The Hybrid mdel is (by definitin) a mix f bth the hub & spke and free-frm mdel. Fr example, the entitlement rules may be held inside the rganizatin and pushed t a PDP, which in itself is a clud service, and then thse decisins are delivered t multiple disparate PEP s that are part f separate clud services. In mre large-scale deplyments, there can be several federated plicy servers that service many different PDP/PEP s. The hybrid mdel will als be fund in rganizatins that mix traditinal and/r legacy cmputing with a (public and/r private) clud envirnment. The hybrid mdel may ffer an efficient use f distributed resurces, but it risks becming cmplex with the attendant scpe fr security lphles t creep in. It als makes lng-term maintenance mre prblematic (the reasning behind simple rules is easy t understand when all wh implemented them are lng gne). The hybrid mdel will als have issues f lgging decisins and actins taken with the ptential need t bring all lgs back int a single place in a cmmn frmat t allw a hlistic view t be taken. The ptential cmplexity f the hybrid mdel stresses the need t be able t use visualizatin tls t develp, maintain, and audit the translatin f the Entitlement Rules int actual access cntrl Level f Trust with Identity and Attributes Identity and Attributes cme with many levels f trust, bth in the varius identities being used in a transactin and with the Attributes attached t thse identities. Traditinally this lack f trust has led t rganizatins having t maintain identities fr anyne wh needs access t their systems, which can be (in sme cases) fr hundreds f thusands f peple wh they d nt emply r directly manage CLOUD SECURITY ALLIANCE 145

147 Sme rganizatins (Military/Aerspace, Pharmaceutical, etc.) that need t cllabrate with a pre-agreed level f trust use a Bridge r Federatin Hub (see sectin 12.4), where trusted identities als have trusted Attributes assciated with them. During the entitlement prcess it is essential t understand nt nly the Attributes required, but als the surce f thse Attributes, the rganizatin that will prvide them, and the strength (level f trust) with which they can be asserted. T accept Attributes frm an external rganizatin with any defined level f trust will require an n-barding prcess fr that rganizatin, and the Identity (Identifier) f the rganizatin that will be asserting thse Attributes. As a rule, the aim shuld be t surce Identity and Attributes frm the master / authritative surce f thse Attributes with all Attributes having a knwn Identity asserting them, as the level f trust that can be placed in the Attribute cannt exceed the level f trust that can be placed in the Identity asserting the Attribute. Where Attributes are being uniquely generated within the clud system itself, then a gvernance prcess must be in place t ensure that all Attributes are accurate and have apprpriate lifecycle management Prvisining f Accunts n Clud Systems Where it is necessary t prvisin an accunt n clud systems (typically fr a user, but it culd be fr any Entity type) there are challenges when prvisining (and de-prvisining) these accunts, as the nrmal push mdel used within rganizatins is generally nt a viable slutin fr a clud implementatin. At the time f writing, there are n widely used r de-fact prvisining standards; SPML 122 (Service Prvisining Markup Language) has nt been widely adpted by the clud prviders, and SCIM 123 (Simple Clud Identity Management) is nly starting t emerge as a ptential standard. The key t prvisining entities n a clud system is t understand the cmplete lifecycle management f an accunt, frm creatin, management, and eventually de-cmmissining (including deletin and/r archiving) acrss all the systems that bth prvide and cnsume the Identity and Attributes. There are sme key issues that need t be addressed with surces f Identity and Attributes when it cmes t prvisining: The link t Human Resurces (r the authritative surce f persn-user infrmatin) is prblematic as HR is ften nly the master surce fr staff n regular payrll. There are usually n authritative infrmatin surces fr partner infrmatin and their devices. The ability t prvisin ther entities (particularly rganizatins and devices) des nt exist in mst rganizatins. Public Identity services generally nly prvide self-asserted Identity and nly abut peple; it des nt extend t the ther Entity types. 122 SPML - Service Prvisining Markup Language 123 SCIM - Simple Clud Identity Management 2011 CLOUD SECURITY ALLIANCE 146

148 De-prvisining needs t extend t all entities, thus mst rganizatins d nt have the ability t ff-bard anther rganizatin when the cntract finishes r revke cde frm perating n systems when it is fund t be faulty r bslete. These issues and the immaturity f prvisining standards stress the need fr gd planning and a hlistic apprach t hw Identity, Attributes, accunts, and lifecycle management f all Entity-types will perate in the clud ec-system being develped Identity-as-a-Service Clud Identity as a Service (IDaaS) 124 is a brad term that cvers the management f any part f the Identity, Entitlement, and Authrizatin/Access Management in the clud service. This encmpasses service fr sftware, platfrm, r infrastructure services, and fr bth public and private cluds. Hybrid slutins are als pssible, whereby identities can still be managed internally within an rganizatin, while ther cmpnents such as authenticatin are externalized thrugh a Service Oriented Architecture (SOA) 125. This effectively creates a Platfrm as a Service (PaaS) layer t facilitate a clud-based IAM slutin. Fr mre infrmatin refer t the sectin cvering Identity-as-a-Service in Dmain 14 Security-as-a-Service Cmpliance & Audit The utcme f the entitlement rules may well need t be lgged tgether with the decisins made by the entitlement rules / authrizatin prcess fr cmpliance r security reasns. Cmpliance and audit is integrally tied t Identity. Withut prper Identity management, there is n way t assure regulatry cmpliance. Auditing als requires prper Identity management, and the use f lg files is f little value withut a wrking Identity system Applicatin Design fr Identity This sectin applies just t applicatin design as it applies t Identity and shuld be read in cnjunctin with Dmain 10 Applicatin Security. Designing clud based systems r applicatins necessitates a change in mindset when it cmes t Identity as Identity and Attribute infrmatin will be cnsumed by the clud service r applicatin, needing t be held fr at least the duratin f the transactin, and prbably sme facets maintained lnger, but because the clud envirnment may likely nt be a part f an rganizatin s physical r lgical jurisdictin, and may even be in a different legal jurisdictin, the service and applicatin design may need t be substantially different frm the design practices used in traditinal client server in a DMZ wned and managed by the rganizatin. 124 IDaaS - Clud Identity as a Service 125 SOA - Service Oriented Architecture 2011 CLOUD SECURITY ALLIANCE 147

149 The design gal shuld be t minimize the need fr Identity and Attributes. When pssible, start frm the principle that identificatin is nt required while understanding the threshld where there will be a need t switch frm basic n-thefly accunt prvisining t an identified user accunt. Examples include: Unique sessins can be established using ther Attributes, e.g., the IP address f the cnnecting device (understanding that IP addresses can be spfed) r a unique sessin ckie. In many cases Attribute-based entitlement alne will be adequate with n need fr user infrmatin r an actual Identity; dn't assume a Persna is needed t tie t a sessin r even an accunt. When encuntering a new Entity fr the first time (say authenticating with a SAML assertin) then create a basic accunt n-the-fly. [Nte that this apprach requires thught abut de-prvisining.] Use Attribute derivatin whenever pssible, (e.g. dn t ask fr date f birth, instead query if ver 18 [if DB > (tday 18 years)]. When generating any unique accunts, decide whether the system will cnsume an external unique Identifier frm the Entity r whether the system will need t generate its wn unique Identifier (such as a custmer reference number). There must be careful thught put int clud systems that maintain user accunts. There must be careful design thught put int hw the clud user accunts will be synchrnized with existing user accunts in ther systems (either internal r ther clud systems), particularly arund the integratin with a jiners and leavers prcess, and the changes in access required when peple mve internally. Designing a clud system t scale (think f 100,000 users with an uncnnected username and/r unsynchrnized passwrd) requires the need t avid frcing a cmmn help desk prcess, including manual r semi-autmated synchrnizatin scripts, passwrd strength validatin prcesses, passwrd reset prcesses, passwrd resets after a cmprmise, etc. all due t a lack f initial design thught abut cnsuming external identities. Avid trying t extend an internal DS int the clud service and/r replicating the rganizatin s DS ver the Internet (generally very insecure) r via a back-channel (leased line r VPN) as this expses an rganizatin s entire DS int an envirnment the rganizatin des nt cntrl. Als be wary f the prmise f RSO (reduced-sign-n) prducts as RSO generally wrks by cmprmising n-lg-in security internally, mre s when trying t extend RSO t a clud envirnment. As a rule, clud services, and thus clud applicatins, shuld accept the standard SSO federatin frmats such as SAML and OAuth (r even the less widely accepted WS-Federatin). When designing an applicatin t cnsume Identity and Attributes, remember that Identity encmpasses all Entities, and that the applicatin security shuld, where pssible, be part f a hlistic apprach that includes all layers; the Netwrk layer; the System layer; the Applicatin layer; the Prcess layer; and the Data layer (as detailed in sectin 12.3). An applicatin culd (fr example) ffer tw methds f cnnecting a full, rich cnnectin using Web/AJAX/Java r an Citrix style screen-scrape cnnectin with the type f cnnectin permitted determined by the Entitlement Rules (defined in the Entitlement prcess) CLOUD SECURITY ALLIANCE 148

150 12.14 Identity and Data Prtectin Hlding aspects f an Identity that cmprises Persnal Identifiable Infrmatin (PII) 126, and particularly infrmatin classified as Sensitive Persnal Infrmatin (SPI) 127, is an issue fr all rganizatins. Clud services managed r lcated utside f the rganizatin will need specialist advice t ensure all applicable laws and regulatins are being adhered t. When cnsidering which laws r jurisdictins might apply, the fllwing (nn-exhaustive) list shuld be cnsidered: All the cuntries f the data subjects The cuntry in which the rganizatin perates Cuntries in which the rganizatin has legal entities Cuntries in which the rganizatin lists n the stck exchange r issues shares The cuntry r cuntries where the clud services are physically lcated The relevant legislatin, regulatins, and als pseud-regulatin (such as PCI-DSS) Cnsumerizatin and the Identity Challenge Interacting with cnsumers and/r cnsumer devices brings a number f challenges and pprtunities in clud-based services and applicatins. The ability f the cnsumer and cnsumer devices t interface directly t an Internet-facing clud service strips away a layer f netwrk cmplexity but intrduces a series f security challenges which can ptentially be mitigated using Identity. Hwever, in the cnsumer space, standards fr device and user Identity are fragmented and (by definitin) will rarely have the same level f cnfrmance and standardizatin that can be achieved in a crprate envirnment. Unfrtunately, mst cnsumer devices and cnsumers themselves have n easy r standard way t enrll themselves r their devices int an authenticatin system prviding strng authenticatin, and thus, authrizatin withut strng Identity is difficult. Even when users have an existing strng authenticatin methd (fr example with their bank) fr ne accunt, this can almst never be reused with anther accunt/prvider. This has resulted in a situatin where Identity fr the cnsumer has already passed the limits f scalability. Over 61 percent f peple use the same passwrd whenever they can 128 ; this results in every additinal registratin r authenticatin causing the lss f ptential custmers. Slving this prblem with seamless access t applicatins will facilitate business, and clear separatin between Identity and authrizatin will facilitate additinal uses, fr example allwing ne individual t delegate use f their Persna linked t a specific credit card n behalf f anther's transactins Identity Service Prviders Cnsuming infrmatin abut Identity frm an external service brings its wn issues. Levels f trust in the prviding rganizatin and validatin f Attributes are just tw examples. Mst current prpsals r actual fferings fr 126 PII - Persnal Identifiable Infrmatin 127 SPI - Sensitive Persnal Infrmatin CLOUD SECURITY ALLIANCE 149

151 cmprehensive and cnsistent Identity framewrks are extraplatins f single r grup players needs by thse with little r n understanding f ther cmmunities needs. Nearly all pen/public cnsumable Identity services deal nly with user verificatin. Thse that ffer persnal infrmatin (Attributes as well as Identity) d s using Attributes that are either self-asserted r nt frm authritative surces. Examples f surces f Identity and Attributes are as fllws: Natinal Gvernment United States, NSTIC strategy & aspiratin nly German EID card, Austrian Citizen Card, Estnian ID Card, Finland Citizen Certificate, Hng Kng Smart ID Card, Malaysian MyCad Public integratin via API's Facebk Amazn Ggle Micrsft Passprt (Windws Live ID) OpenID prviders (Varius) Twitter Bridges 129 r Hubs Research / Educatin Bridge (REBCA 130 ), serving the US higher educatin sectr Federal PKI Architecture (Federal Bridge) serving all US federal agencies. CertiPath/Transglbal Secure Cllabratin Prgram 131, serving the aerspace and defense industries SAFE-BiPharma Assciatin 132, serving the bipharmaceutical and healthcare industry Identity Service fferings Check / validate my pstal cde and address (varius) Experian / Equifax 3D card verificatin (Visa/MasterCard) / CLOUD SECURITY ALLIANCE 150

152 ebay / PayPal / X.Cmmerce Recmmendatins Federatin Recmmendatins Cnsumers, Implementers, and Prviders shuld agree n the cntext and definitin f federatin being used. Implementers shuld understand what trust relatinship and transitive trust exist and the need fr bi-directin trust relatinships. Implementers shuld, where pssible, use federatin based n pen standards such as SAML and OAuth. If using a Bridge r Federatin Hub, then Implementers shuld understand the nature and relatinship f the trusts that exist between different members f the club. Understand what it culd mean t yur entitlement rules if there is anther member signed up t the clud r federating t anther bridge. Implementers shuld understand that public Identity prviders such as Facebk, Yah, r Ggle prvide a surce f (lw grade, typically self-asserted) Identity with n guarantees that they will nt federate t ther prviders in the future. Implementers shuld deprecate examples f bad slutin design slutins t get Identity frm a DS linked int the access management system f a clud slutin. Such examples include in-band VPN s and ut-f-band leased-lines Prvisining and Gvernance Recmmendatins All Attributes shuld be surced frm as clse t the authritative / master surce as pssible. As a rule, the clud service r applicatin itself shuld avid being the master surce fr Identity. The clud service r applicatin itself shuld nly be the master surce fr Attributes it directly cntrls. All Attributes cnsumed shuld have a knwn level f trust. All Attributes cnsumed shuld be linked t an Identity. The Identifier f a defined Entity shuld sign all Attributes cnsumed. Each Attribute shuld have a lifecycle that is fit-fr-purpse. Each Identity (and related Identifier) shuld have a lifecycle that is fit-fr-purpse Entitlement Recmmendatins All parties in the entitlement (definitin) prcess shuld be clearly identified CLOUD SECURITY ALLIANCE 151

153 There shuld be clear designated respnsibilities fr entitlement rule apprval and sign-ff. A prcess t manage changes t the Entitlement Rules shuld be clearly defined. A frequency (r trigger) fr auditing the Entitlement Rules shuld be clearly defined. The entitlement prcess shuld fcus n prducing Entitlement Rules that are simple and minimal and designed using the principle f least privilege. The entitlement prcess shuld fcus n prducing entitlement rules that minimize the expsure f Identity r avid needing t cnsume Identity altgether. Attributes that are tempral (such as gelcatin) need real-time Attribute checking thrugh a lifetime f transactin t revalidate the entitlement rules. Entitlement rules shuld be triggered by a prcess (r attempt t initiate a prcess, such as mney transfer ut f envirnment). In sme envirnments, best practice wuld be fr the entitlement rules t disable such functins. In thers, best practice wuld be t require additinal Identity r Attributes at the pint f executin t ensure the Entity is entitled t perfrm the prcess. Implementers shuld ensure bi-directinal trust t ensure the ptimal secure relatinship fr the transactin. The entitlement prcess shuld define this. The design f the entitlement rules shuld include delegatin 133 f access by a secndary Entity t sme, but nt necessarily all, infrmatin the primary Entity can access. The design f entitlement shuld include the seizing f access (including legal seizure), althugh the designer f the entitlement rules will need t take int accunt the jurisdictin f the system, rganizatin, and entities invlved. Legal advice must be taken prir t implementing any seizure f access. Where practical, management interfaces, tls, r ther visualizatin technlgies shuld be used t help in management f Entitlement and t help ensure the interpretatin meets the business and/r regulatry (e.g. SOX Segregatin-f-Duties) requirements Authrizatin and Access Recmmendatins Implementers shuld ensure services have an imprt and/r exprt functin int standards such as OASIS XACML. When using a PDP in a clud envirnment, implementers shuld understand hw authrizatin decisin lgging wuld be extracted and/r integrated int an rganizatin lgging fr a hlistic picture f access. Implementers shuld ensure existing (legacy) services can interface with PEP/PDP s. Implementers shuld ensure any PDP is adequate t prperly translate the entitlement rules defined in the entitlement prcess. 133 Delegatin is newly supprted in XACML CLOUD SECURITY ALLIANCE 152

154 Implementers shuld cnsider the use f plicy-as-a-service as the plicy server if there is a need fr a central plicy server (fr example fr clud mashups) Architecture Recmmendatins Implementers shuld ensure any clud prvider ffers authrizatin management PEPs/PDP s that can be cnfigured with entitlement rules. Implementers shuld ensure that all cmpnents f the Identity, Entitlement, and Authrizatin / Access Management (IdEA) wrk crrectly tgether. Implementers shuld ensure that Plicy Decisin/Enfrcement Pints (PEP s/pdp s) use standard prtcls (e.g. XACML) and avid (r depreciate) prprietary prtcls (e.g. direct web service r ther middleware calls). Implementers shuld ensure any strng authenticatin service is OATH 134 cmpliant. With an OATH-cmpliant slutin, rganizatins can avid becming lcked int ne vendr s authenticatin credentials. Clud services and applicatins shuld supprt the capability t cnsume authenticatin frm authritative surces using SAML. Implementers shuld ensure services have an imprt and/r exprt functin int standards such as OASIS XACML. Implementers shuld ensure services can interface with PEP/PDPs installed in the clud infrastructure and with Plicy Mnitring Pints fr incident mnitring/auditing. Implementers shuld ensure that lgging f authrizatin decisin and access actually granted can be lgged in a cmmn frmat using standard secure prtcls Entitlement Recmmendatins Implementers shuld ensure that each Identity and Attribute defined in the entitlement prcess matches the level f trust that is needed (r is acceptable) in bth the Identity/Attribute itself and als matches the surce that prvides it. Implementers shuld ensure all surces f Identity / Attributes prvide rganizatinal Identity. Implementers shuld ensure that Attributes are validated at master / surce whenever pssible, r as clse as pssible. Implementers shuld ensure Attribute use crrectly leads t the right cnclusin. (Yur cntext may be different t the riginatr f the Attribute) Implementers shuld ensure that the Identity / Attribute surce has bth the standards f data quality and a gvernance mechanism that meets yur needs. 134 OATH- Open Authenticatin Reference Architecture, CLOUD SECURITY ALLIANCE 153

155 Cnsumers shuld be aware that reputatinal trust can be an imprtant surce f trust. Thrugh the entitlement definitin, cnsumers shuld be aware f small value transitins, leading t an increase in transactinal trust, which may be defrauded n a subsequent large transactin Prvisining Recmmendatins Prviders shuld understand whether SPML r SCIM culd be a viable ptin fr prvisining. Implementers shuld fllw the rule f least privilege when prvisining an accunt. In the case f entities such as cmputing devices, a link t rganizatinal asset registries is desirable. Mst systems and applicatins have a ne-t-ne relatinship between the user and access and n cncept f delegatin. Implementers shuld ensure that prvisining and de-prvisining are nt limited t user identities. Architectures must include authrizatin fr all Entity types. Implementers shuld ensure prvisining and de-prvisining are dne in real time. Prviders shuld ensure the maintenance f bth Identity and Attributes are critical if entitlement is t be accurate Identity Cmpliance & Audit Recmmendatins Implementers shuld ensure that the applicable lgs frm the entitlement rules / authrizatin prcess are capable f being made available. Implementers shuld ensure where lgs need t be integrated int a wider (pssibly remte) system (e.g. fr wider fraud detectin r segregatin f duties analysis) t ensure the availability, timeliness, frmat, and transmissin security f the lgs is adequate. When lgging access decisins, implementers shuld grup the Attributes tgether with the entitlement lgic used at the time f the decisin, and the utcme shuld be recrded. All clud participants shuld remember that Attributes with a tempral cmpnent might need t be revalidated, and hence re-lgged, during the lifetime f the sessin. When lgging PII r SPI then, whenever pssible, implementers shuld use Attribute derivatin t minimize the expsure f PII r SPI in the lgs. Cnsumers shuld be aware that lgs cntaining PII r SPI will be subject t data prtectin legislatin Applicatin Design Recmmendatins Implementers shuld use ITU X.805 / 3-layer definitin f User, System, and Management layers t ensure segregatin CLOUD SECURITY ALLIANCE 154

156 Implementers shuld minimize the need fr Identity and Attributes in an applicatin design. When pssible, design clud systems t cnsume Identity and Attributes frm external surces. Implementers shuld ensure the clud system supprts standard SSO federatin frmats such as SAML and OAuth. Implementers shuld take a hlistic apprach t security, using Identity and Attributes acrss all the layers f the system. Implementers shuld remember that mutual authenticatin is critical at all levels, and even mre imprtant in clud envirnments, just as the clud envirnment needs entities and ther systems t authenticate wh they are, s the clud system needs t be able t authenticate in return Data Prtectin Recmmendatins Implementers shuld minimize the use and strage f PII r SPI. This shuld be dne in the design phase f the entitlement prcess t ensure nly Identities and Attributes essential t the prcess are used. The implementer shuld cnsider the fllwing technlgies t minimize expsure f PII r SPI: Encryptin Tkenizatin Hmmrphic Encryptin 135 Refer t Dmain 11 Encryptin & Key Management fr mre infrmatin. Implementers shuld cnsider using best practice appraches t prtecting SPI such as using a dual-key apprach, ne held by the subject (r keyed against their lg-in), and ne by the system fr use with prcessing. Implementers shuld understand hw administratr access t PII and SPI might be restricted r stpped. Implementers shuld understand hw a Subject Access Request 136 can be dealt with in the legal timeframe mandated especially when the data may be held n a clud system nt wned / managed by the rganizatin that received the request. If there is a need t share PII r SPI, cnsumers shuld understand hw the apprval f the subject f the PII/SPI will be btained. Implementers shuld reduce PII/SPI being stred, especially when nt the authritative surce, and nly reference thse attributed frm the authritative surce rather than stre (and maintain) them. Implementers shuld understand the prcesses by which the maintenance f PII/SPI (whether Identity r Attributes) will be handled in a timely manner. 135 At the time f release, Hmmrphic Encryptin is currently in the early stages f prduct implementatin. 136 A Subject Access Request is the legal right in sme cuntries t request any PII r SPI held abut yurself 2011 CLOUD SECURITY ALLIANCE 155

157 Identity Implementatin Recmmendatins Implementers shuld start frm the principle f Identity re-use rather than the unique enrllment f new users and/r devices. Cnsumers shuld understand where existing surces f Identity can prvide sufficient levels f trust and be reused. Prviders shuld understand what Attributes abut the user and devices can be asserted t a sufficient level f trust fr the transactin being undertaken. When apprpriate, cnsumers shuld allw lw risk transactins t take place using lw grade level f authenticatin. Only escalate the Identity required when the transactin value / risk increases. Prviders shuld prvide a critical assessment f the Identity and Attributes being required during the Entitlement Prcess when cnsidering cnsumers and cnsumer devices. Prviders shuld understand what technlgies can be used with cnsumer devices t increase assurance levels, especially technlgies than can be used in the backgrund. Cnsumers shuld understand where the management f cnsumer devices will nt be perfrmed and the level f assurance this prvides; this culd range frm n assurance t gd assurance. Cnsumers shuld understand where a level f assurance and legal liability resides shuld an issue arise with a transactin frm a cnsumer device Requirements Implementers must design the cmmn service layers t act independently t enable the remval f applicatin sils withut sacrificing existing infrmatin security plicies and prcedures. All clud participants must respect the integrity f the supply chain and respect existing IAM practices in place. Elements such as privacy, integrity, and audit ability must be respected. Identity integrity and audit must be preserved when mving data ff-site and/r decupling the pillars f the slutin int web service architecture CLOUD SECURITY ALLIANCE 156

158 DOMAIN 13 // VIRTUALIZATION Virtualizatin is ne f the key elements f Infrastructure as a Service (IaaS) clud fferings and private cluds, and it is increasingly used in prtins f the back-end f Platfrm as a Service (PaaS) and SaaS (Sftware as a Service) prviders as well. Virtualizatin is als, naturally, a key technlgy fr virtual desktps, which are delivered frm private r public cluds. The benefits f virtualizatin are well knwn, including multi-tenancy, better server utilizatin, and data center cnslidatin. Clud prviders can achieve higher density, which translates t better margins, and enterprises can use virtualizatin t shrink capital expenditure n server hardware as well as increase peratinal efficiency. Hwever, virtualizatin brings with it all the security cncerns f the perating system running as a guest, tgether with new security cncerns abut the hypervisr layer, as well as new virtualizatin specific threats, inter-vm (Virtual Machine) attacks and blind spts, perfrmance cncerns arising frm CPU and memry used fr security, and peratinal cmplexity frm VM sprawl as a security inhibitr. New prblems like instant-n gaps, data cmingling, the difficulty f encrypting virtual machine images, and residual data destructin are cming int fcus. Overview. While there are several frms f virtualizatin, by far the mst cmmn is the virtualized perating system, and that is the fcus fr this dmain. This dmain cvers these virtualizatin-related security issues: Virtual machine guest hardening Hypervisr security Inter-VM attacks and blind spts Perfrmance cncerns Virtualizatin brings with it all the security cncerns f the guest perating system, alng with new virtualizatin-specific threats. Operatinal cmplexity frm VM sprawl Instant-n gaps Virtual machine encryptin Data cmingling Virtual machine data destructin Virtual machine image tampering In-mtin virtual machines 2011 CLOUD SECURITY ALLIANCE 157