</CLOUD>

A high level talk on some aspects of 'Cloud' security given with Ýmir Vigfússon to a financial services security interest group in Iceland.

Transcript

1. Ýmir Vigfússon Rich Smith </CLOUD>  
2. •  Ýmir  Vigfússon,  PhD   – Now:  Prof.  of  Computer  Science,  Reykjavík   University  &  Chief  Science  Officer  of  Syndis   – Prior:  IBM  Research,  Yahoo  Research,  ...   – Where:  Reykjavík   •  Rich  Smith   – Now:  Principal  Researcher  and  CEO  of  Syndis   – Prior:  VP  at  Morgan  Stanley,  HP  Labs,  ...   – Where:  NYC  &  Reykjavík  
3. Who  are  Syndis?     •  Group  of  offensive  security  professionals  who   use  aHack  simulaJons  against  our  clients  to   help  them  understand  real-­‐world  threats   •  We  focus  on  bespoke  aHack  technology  for   clients  who  need  deep  security  insight  
4. •  Rapidly  changing  area  of  technology   •  Example  of  how  aHack  opportuniJes  are  created   •  ARackers  understand  more  about  the  security   implicaJons  of  a  technology  change  than  you  do   CLOUD  SECURITY  
5. CLOUD  
7. Before  the  cloud   Reality   Capacity   Requests   Time   Your  users  flee   Bad  uJlizaJon   Capacity  does   not  track  reality  
8. —  Maximum  capacity  should  track  reality   ElasScity   Reality   Capacity   Requests   Time  
9. Up  to  the  clouds   Pros   Lower  capital  and   operaSng   expenditures   Simple  to  use   AHributes   Reliability   ElasScity   Virtual  environment   Distributed  hosSng   Types   IaaS   PaaS   SaaS  
10. Up  to  the  clouds   Clouds  are  an  elasJc,  reliable   operaSng  environments  that  share     common  resources  and  meter  usage   (as  well  as  quality)   Pros   Lower  capital  and   operaSng   expenditures   Simple  to  use   AHributes   Reliability   ElasScity   Virtual  environment   Distributed  hosSng   Types   IaaS   PaaS   SaaS  
11. Cloud  layers   SoXware-­‐as-­‐a-­‐Service   • Google  Docs  /  Gmail   • Salesforce   Pla\orm-­‐as-­‐a-­‐Service   • Google  App  Engine   • Amazon  Beanstalk   • MicrosoX  Azure  /  365   Infrastructure-­‐as-­‐a-­‐Service   • Amazon  EC2   • Rackspace.com   ApplicaJons   Data   Run-­‐Jme  environment   OperaJng  system   Virtual  machines   Equipment   Data  storage   Networking  equipm.   Security  team  
12. Cloud  layers   SoXware-­‐as-­‐a-­‐Service   • Google  Docs  /  Gmail   • Salesforce   Pla\orm-­‐as-­‐a-­‐Service   • Google  App  Engine   • Amazon  Beanstalk   • Heroku   Infrastructure-­‐as-­‐a-­‐Service   • Amazon  EC2   • Rackspace.com   ApplicaJons   Data   Run-­‐Jme  environment   OperaJng  system   Virtual  machines   Equipment   Data  storage   Networking  equipm.   Security  team  
13. ApplicaJons   Data   Run-­‐Jme  environment   OperaJng  system   Virtual  machines   Equipment   Data  storage   Networking  equipm.   Cloud  layers   SoXware-­‐as-­‐a-­‐Service   • Google  Docs  /  Gmail   • Capsule   Pla\orm-­‐as-­‐a-­‐Service   • Google  App  Engine   • Amazon  Beanstalk   • Heroku   Infrastructure-­‐as-­‐a-­‐Service   • Amazon  EC2   • Rackspace.com   Security  team  
14. DelegaSon  of  trust   —  The  cloud  has  many  layers  –  it  is  not  flat     ◦  What  if  Capsule  uses  Heroku,  which  in  turn  uses   Amazon  EC2?   —  It  may  not  even  be  possible  to  know  where  data   is  geographically  stored   ◦  Can‘t  dictate  data  locaJon  for  cloud  providers   ◦  Historic  knowledge  of  where  it  is  does  not  predict   where  it  will  be  in  the  future  
15. DelegaSon  of  trust   —  Do  trust  concerns  stop  companies  from   migraSng  to  the  cloud?   ◦  „More  than  33%  of  company  budgets  spent  on  cloud   services“  (Forbes  [1])   ◦  „79%  of  cloud  providers  allocate  less  than  <10%  to   security“  (Ponemon  InsStute  [2])   ◦  100%  of  aRackers  approve!   [1]  hRp://blogs.wsj.com/tech-­‐europe/2011/04/29/cloud-­‐providers-­‐not-­‐concerned-­‐by-­‐security   [2]  hRp://www.ca.com/us/~/media/Files/IndustryAnalystReports/2012-­‐security-­‐of-­‐cloud-­‐computer-­‐users-­‐final1.pdf  
16. •  Rapidly  changing  area  of  technology   •  Example  of  how  aHack  opportuniJes  are  created   •  ARackers  understand  more  about  the  security   implicaJons  of  a  technology  change  than  you  do   CLOUD  SECURITY  
17. SECURITY  
35. ATTACKING IS AN ENTERPRISE Found the original bug by fuzzing Wrote a proof-of- concept exploit Wrote a DEP- resistant exploit Weaponized the exploit Created post- exploitation framework Sponsored the attacks Administered deployment
37. •  <The  situaSon  is  highly  asymeRric>   ASYMMETRY
38. So,  how  do  you  aRack  the  cloud  ?   •  You  are  using  the  cloud  for  a  reason   – Lowering  barriers  to  entry:  a  startup  can  have  a   full  IT  setup  without  upfront  costs   – DelegaJng  responsibility  for  saving  on  costs  and   complexity   – Technology  is  complicated  and  a  distracJon.             Let  someone  else  worry  about  that   – All  of  these  advantages  also  have  trade-­‐offs  
39. So,  how  do  you  aRack  the  cloud  ?   •  ARackers  take  advantage  of  these  features     – Focus  on  those  tradeoffs  and  compromises   – IdenSfy  the  features  of  the  cloud  you  rely  on  that   also  provide  them  aRack  advanatage   •  What  are  the  opportuniJes  for  aHackers?   – We‘ll  give  real-­‐world  examples   – Flaws  -­‐  not  bugs  
40. FLAW   BUG  
41. #0  Clouds  are  opaque   •  Log  availability  is  limited   –  IaaS:  Amazon  S3  does  not  provide  connecSon  logs   –  PaaS:  Logs  in  Google  Apps  (e.g.  Gmail)  have  no  ‘SLA’   could  arrive  0-­‐48  hours  later   •  Thus  you  will  likely  not  see  either  successful  or   failed  log-­‐in  aHempts  at  all  or  in  a  Smely  manner   •  You  are  at  the  mercy  of  your  provider    
42. #1  Clouds  are  accessible   •  Different  requirements  for  access  control   – Clouds  &  OpenAPIs  go  hand  in  han   – API  tokens  /  certs  are  the  keys  to  the  kingdom   – Opaque  with  respect  to  logging   •  Example:  Amazon  S3  credenSals   – Full  remote  access  via  API  keys  /  cerSficates   – We‘ve  found  AWS  admins  keys  on  publicly   accessible  websites,  giving  access  to  everything  
43. #1  Clouds  are  accessible   •  But  what  about  two-­‐factor  authenJcaJon?   •  User  interface  Vs.  ProgramaSc  Interface   – Different  security  models  &  requirements   •  Example:  Gmail  servers.   – May  enforce  2-­‐factor  authenScaSon  for  users   – But  the  API  allows  you  to  sidestep  them  
44. #2  Clouds  are  leaky   •  The  cloud  is  foundaJonal  to  many  companies   and  organizaSons   – Tech  companies  are  very  fast  adopters   •  Lots  of  trust  placed  in  cloud-­‐based  services  
45. #2  Clouds  are  leaky   •  Example:  HipChat   – Private  group  chat  and  team  collaboraSon   – All  files  or  images  are  stored  in  Amazon  S3   – ProtecSon  is  based  on  not  knowing  the  URL   – Google  search  for  “site:s3.amazonaws.com  inurl:/ uploads.hipchat.com”  
46. #2  Clouds  are  leaky   •  Example:  GitHub  /  Gist   –  The  social  network  of  soXware  developers   –  Companies  and  individuals  push  their  code  into  these   services     –  We‘ve  found  lots  of  sensiJve  data  pushed  unwizngly   •  CredenSals  (SSH    keys,  database  credenSals)   •  Internal  documentaSon   •  Internal  infrastructure  informaSon   –  What  applicaSons  are  being  used?   –  Internal  network  set-­‐up  and  structure   –  ARackers  care  about  ROI  –  we  hired  a  summer  intern!  
47. #3  Clouds  get  everywhere   •  Even  if  you  think  you‘re  not  using  the  cloud,   you  may  sSll  be   •  Example:  MacOS  X:  Unsaved  docs  &  iCloud   – Enter  AppleID  at  install  Sme,  iCloud  auto-­‐enabled   – Your  documents  are  stored  locally...   – ...but  unsaved  files  in  apps  supporSng  the  iCloud   API  are  automaScally  pushed  into  iCloud   – This  is  unexpected  to  most  !   hRp://support.apple.com/kb/TS4372  
48. OS   Cloud   App  
49. #3  Clouds  get  everywhere   •  This  a  trend  which  is  ongoing  &  not  just  OS  X   •  Has  significant  impact  to  long  established   security  models  and  boundaries   •  Not  just  network  de-­‐perimiterisaSon  but  the   break  of  the  OS  perimeter   hRp://support.apple.com/kb/TS4372  
50. ARackers‘  takeaways   •  In  the  cloud,  your  tracks  are  harder  for   people  to  see   •  Cloud  users  don’t  understand  the  changes  to   their  security  boundaries  of  the  new  model   •  API  keys  are  everywhere  and  are  the  keys  to   many  kingdoms   •  RegulaJons  fail  to  keep  up  !=  security  
55. HOW MUCH DO I SPEND ON DEFENSE X? HOW MUCH DOES AN ATTACKER HAVE TO SPEND TO BYPASS X? HOW MUCH IS DEFENSE X ACTUALLY WORTH TO ME? WHAT IS BYPASSING DEFENSE X WORTH TO AN ATTACKER ?
57. If  you  take  nothing  else  away     Tradeoffs     Asymmetries      
58. Clouds  trade  off  control  for  lower  costs   Caveat:  Also  reduces  security  granularity   Clouds  reduce  operaSonal  complexity   Caveat:  Increase  security  complexity   Cloud  environments  constantly  evolving   Caveat:  Security  understanding  must  evolve  also  
59. Ýmir Vigfússon ymir@syndis.is Rich Smith rich@syndis.is #TheSyndis