Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to What Everyone Ought To Know About Cloud Security
Similar to What Everyone Ought To Know About Cloud Security (20)
Recently uploaded
Recently uploaded (20)
What Everyone Ought To Know About Cloud Security
- 1. What Everyone Ought To Know About Cloud Security Craig Balding cloudsecurity.org 20/10/09 | Session ID: BUS-106 Classification: Intermediate
- 2. Agenda Decomposing Cloud Objectives Understand Implementations Applying Security
- 3. Objectives
- 5. Cloud is the New Pink
- 6. Who Said This? "We will make cloud computing announcements, because if orange is the new pink, we'll make orange blouses"
- 8. Cloud vs. Grid Google Trends
- 10. BUT Cloud != Virtualization
- 11. “ ABSTRACTION !”
- 12. Defining Cloud “… the market seems to have come to the conclusion that cloud computing has a lot in common with obscenity--you may not be able to define it, but you'll know it when you see it” James Urquhart – The Wisdom of Clouds
- 15. Cloud Layers Jericho Forum
- 16. Cloud Security?
- 18. Cloud Cube Model Jericho Forum
- 19. Public Cloud: MS Azure
- 20. Public Cloud: Amazon Web Services
- 23. Private Cloud
- 24. Key Cloud Security Controls
- 25. How Much Time Do We Have? 80 pages
- 27. It’s all about Workloads…
- 28. … and Providers!
- 29. SSL/TLS Is Not The Cure-All
- 30. … nor is Hiding Behind Contracts
- 32. The Hypervisor
- 34. InterCloud VPN
- 37. API Security
- 39. Billing
- 40. Change Control “… someone once likened the process of upgrading our core websearch infrastructure to “ changing the tires on a car while you’re going at 60 down the freeway. ” Urs Holzle – SVP Operations, Google
- 41. ToS & SLA
- 42. Legal
- 43. Audits The Tour On/off-site “ Certification” Change Control Security Awareness SDLC, Scans/Testing
- 44. Visibility Provider actions Admin activity Intrusion Detection A6 Working Group
- 46. Further Reading & Contact Cloud & Cloud Security http://cloudsecurity.org/resources Email : [email_address]
- 47. Appendix
- 48. Cloud Model: Infrastructure (IaaS) Chris Hoff
- 49. Cloud Model: Platform (PaaS) Chris Hoff
- 50. Cloud Model: Software (SaaS) Chris Hoff
Editor's Notes
- NPR Interview 1 month after starting cloudsecurity.org (!) Google Alerts on “cloud security” UP from 3 per day to 50 per day Google Trends
- Who said this? The cloud “haters” felt they’d found a leader
- Larry Ellison’s famous quote on Cloud Largely seen as sideswipe at the emerging cloud industry
- Google search volume globally Who heavily marketed Grid? ORACLE
- But hold on Larry Didn’t you recently acquire Sun? And then VirtualIron? Translation: Larry now owns 3 hypervisors, a core technology of infrastructure clouds (note: there are different clouds and some don’t rely on hypervisors) Even the apparent cynics recognise the business opportunity.
- Cloud is not virtualization.
- As Google will correctly tell you, there are more paths to cloud than virtualization. It’s all about ABSTRACTION Virtualization is *ONE* form of abstraction. An important form, but not the only way. Take Google AppEngine – no virtualization anywhere. More a fabric – an army of commodity machines knitted together with distributed software. Not a hypervisor in sight… “ The fabric’s role is to abstract the underlying physical and logical architecture from the developer, and - typically - to assume the burden of scaling. “ – James Urquhart
- Notably, Jericho defines 5 layers showing 4 points of abstraction Going from the bottom: Infrastructure: the ‘compute’, ‘storage’ and ‘network’ layer. Sysadmin focus. Platform: a sort of ‘application toolbox’ layer, abstracting away visibility of infrastructure. Developer focus. Software: a finished application, delivered as a service Process: XXX Outcome/value: XXX
- “ Mr Hare, I trump your agility with my security!” said Security Tortoise craning his neck to see if the hare was indeed still there. An article in CFO mag put it like this: “ But like Linux, Blackberries, and iPhones, cloud computing will allow business units to elude outdated IT policies until they can be updated” Review a model by Chris Hoff that links cloud layers to specific security controls we all know and love.
- The Cloud Cube gives us a handy lense through which to view cloud deployment scenarios, or formations Jericho uses 4 criteria to differentiate cloud “formations” external/internal; is the cloud inside your org or off-site? Propietary/open: who owns what? How interoperable is the service? How easily can I move my data & applications? This is about portability/lock-in Limitations on sharing applications Perimeterised/De-peremeterised architectures: a primary theme of the JC acknowledging the connectedness required for effective collaboration and the impact that has on our traditional perimeter controls (see COA: Collaboration Oriented Architecture) Insourced/Outsourced:your own staff vs. 3 rd party (I.e. a policy issue) Ultimately cloud can offer a level of agility business longs for, that IT departments struggle to deliver on.
- Walkthrough highlighting security features & published security policy.
- Walkthrough highlighting security features & published security policy.
- Walkthrough highlighting security features & published security policy.
- Amazon VPC Define “isolated”: single NIC switched between public/customer specific VPC? Lack of technical details: Black Box – “Trust us” Amazon Security Whitepaper doesn’t track improvements/changes in a timely way
- DC conversion – leverage existing compute/storage/network Also for traditional hosting providers seeking to become ‘cloud providers’ Walkthrough highlighting security features.
- Earlier we reviewed the key attributes of a cloud service – now we consider some of the specific security issues and control options around those.
- Before getting giddy over a cloud provider that introduces your favourite security control ™ and jumping on, we need to take a step back. We need to identify workloads that are suitable for cloud processing/storage. A workload could be a defined set of data (storage as a service), an application (SaaS) or a legacy application bundled inside a VM (IaaS). How do we do this? Hopefully we have an asset inventory and owner, not just physical assets, but applications and perhaps, even information (or at least buckets of information associated in some way). Those assets need to be mapped to our data classification scheme. Again, if we don’t have one, we need one! With knowledge of what we have, how sensitive it is, what are responsibilities are and how “connected” it is to other systems and other parties we can start to make informed choices. By making our decisions based on organisations tolerance of risk (which should be embodied in actionable security policies). If we can’t articulate this, this is a red flag. Don’t pass to Cloud. Fix this first. So, its all about workloads…and…
- Providers. Cloud providers. What makes a cloud provider different from a traditional provider? <PAUSE> They run cloud platforms that meet the criteria we talked about earlier. Each of those criteria have associated security concerns. How well your provide does at figuring those out and building controls that fit your appetite for risk Once you’ve figured out what workloads you have that may be suitable for cloud today, you’ll need to find a suitable provider. Cloud is immature today and the assurance around cloud implementations often (but not always) reflect this. You may in fact wish to be your own provider. More likely you’ll mix and match workloads to providers (external/internal and public/private) based on criticality, sensitivity etc. As resources are shared at a logical level rather than a physical level, you need to find out from prospective cloud providers how they keep things separate and very importantly, what proof they have that their controls are working in the face of a determined, intelligent adversary. Ultimately the controls need to be “resistant enough” (you get to define how much based on context) to attack & able to comply with whatever policies apply to your org Therefore, we need to map workloads to required security controls and in turn map those to providers (and assurance levels we need) That means revisiting our security policies, data classification and matching cloud provider security controls with workloads.
- SSL and now TLS are important network security protocols but they are not a cure-all but that’s how we’ve been treating them from a web app and services perspective. The applied research from Moxie Marlinspike alone has provided enough evidence that putting all our eggs in one basket – one security control – is ultimately sloppy engineering. However, SSL is often the key control touted by Cloud providers…
- … customers on the other hand may be tempted to hide behind contracts. Contracts with Cloud service providers are important of course but they do NOT relieve us of our obligations. We are still accountable even if another party is executing on our behalf. There will be those that ‘blame the cloud provider’ but this won’t wash for regulated entities – you auditors will be looking at you.
- Lets talk about some of the Cloud Technology specific concerns.
- Hypervisor security has so far won lions share of vuln research. hypervisor thinning Commodity But cloudsec is more than virtsec.
- Brand new cloud platforms – stitching together open source software. The provider makes the “custom” glue. Is responsible for updating libraries etc when vulns discovered. Fresh attack surface..
- All the usual VPN security concerns – nothing particularly new here but clearly, breaking into a VM that provides a VPN bridge back into a customer is a concern.
- Distributed storage – eventually consistent (amazon s3) – distributed programming challenge
- Federation Identify is not a solved in the enterprise, let alone on the Internet As we migrate some workloads to the cloud, so we need to think about how we transfer identities. Kim Cameron – now at MS has done some pioneering work in this area. Recommend reading the laws of identity to understand the background to claims and assertions.
- API security: WS* etc. Easier said than done. All the classic web services issues + multiple providers aka multiple “origins” with no direct browser support for XML crypto etc. XML Parsers Monitoring of API usage (note sensepost research highlighted this isn’t happening at the providers). EC2 Wrap around attacks etc. Bad crypto x 2
- Lets talk about some of the Cloud Technology specific concerns.
- Cloud Billing systems are brand new – sparkly new. Hard to design – read the blogs of the billing systems designers (you can bet the bad guys will) For the cloud customer they have to care about: Accuracy Payment methods Soft / hard limits Financial DoS Missed payments -> data retention 60 days, 90 days? So those are some of the technology concerns…what about the non-technology concerns?
- OK so this quote was about their websearch infrastructure. But how often do you see a ‘we’re going down for maintainance sign?” And before that he said: “ Configuration issues and rate of change play a pretty significant role in many outages at Google” “ We’re constantly building and rebuilding systems” And what about TRANSPARENCY…over unfixed security issues? Providers have a real balancing act here.
- Critically important to thoroughly read Terms of Service agreements and SLAs. SLAs 99.5% uptime – public cloud. Internal uptime metrics? ToS: focus on: data ownership Data retention/deletion clauses (non-payment etc) Generally, zero liability, at best service credits
- Cross border FBI Data Center Seizure E-discovery Data destruction Cloud Failure: legal rights
- All the classic outsourcing questions BUT in a highly dynamic, cloud environment. Where do you plumb in your NIDS/NIPS? Introspection possibilities Background story on A6 Working Group How to join.
- Infrastructure as a Service: Amazon EC2, GoGrid, Flexiscale Facilities – the Data Center: Power, HVAC & Floorspace Hardware – The silicon: compute, network storage Abstraction & Core Connectivity & Delivery: sat between hardware & API’s – the “magic glue” APIs: This is the customer facing API, the management interface… Provides a way for customers to consume the services. Changes as additional features are added.
- Platform as a Service Integration & Middleware on the left Breaks out to Database, Messaging, Queuing & IAM/Auth Examples: Google AppEngine, Force.com
- Decomposing the layers to better wrap our heads around somewhat abstract concepts.