Securing The Cloud

1,283 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,283
On SlideShare
0
From Embeds
0
Number of Embeds
30
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Securing The Cloud

  1. 1. Securing the Cloud (Don’t get lost in the fog) Chris Munt M/Gateway Developments Ltd
  2. 2. Topics <ul><li>Real World View </li></ul><ul><ul><li>Assessing risk </li></ul></ul><ul><li>Corporate/Lawyers View </li></ul><ul><ul><li>Analysis of commercial risk </li></ul></ul><ul><li>Technical View </li></ul><ul><ul><li>Using technology to mitigate risk </li></ul></ul>
  3. 3. Real world view
  4. 4. Assessing risk What risks are you exposed to?
  5. 5. Assessing risk
  6. 6. Assessing risk Indentify weaknesses
  7. 7. Assessing risk Can technology help?
  8. 8. Assessing risk Source: XKCD web comic: http://xkcd.com/
  9. 9. Assessing risk Lost in the fog of fanciful terms used to describe technology?
  10. 10. Assessing risk Cyberspace Virtualization Cloud computing Private Cloud Public Cloud Hybrid Cloud Cloudware IaaS, PaaS, SaaS
  11. 11. Assessing risk Cloud Computing <ul><ul><li>Real computers
  12. 12. Real databases
  13. 13. Real networks </li></ul></ul>Who’s watching you?
  14. 14. Assessing risk What about human factors?
  15. 15. Assessing risk
  16. 16. Assessing risk
  17. 17. Assessing risk “ You must change your password every few weeks and it must be constructed from no less than twelve characters which will include a mixture of upper and lower case letters, digits and punctuation characters”
  18. 18. Assessing risk Security versus Convenience?
  19. 19. Assessing risk
  20. 20. Assessing risk Why would anyone want to break your security?
  21. 21. Assessing risk
  22. 22. Assessing risk What’s your data worth to you? What’s it worth to someone else?
  23. 23. Assessing risk Lindisfarne Castle, Holy Island ~1797 by Thomas Girtin (1775–1802)
  24. 24. Assessing risk <ul><li>Best security is data locked in a secure room </li></ul><ul><ul><li>Not practical </li></ul></ul><ul><li>Sensible compromise required </li></ul><ul><ul><li>Must be practical with safeguards against all likely risks </li></ul></ul>
  25. 25. Corporate/Lawyers view
  26. 26. Cloud Computing: Risks to an organization <ul><li>Focus on Security and Accountability
  27. 27. Gartner report June 2008 </li></ul><ul><ul><li>Identify seven areas of risk
  28. 28. Suggest questions to be directed at service provider
  29. 29. Reference: </li><ul><li>http://www.infoworld.com/article/08/07/02/Gartner_Seven_cloudcomputing_security_risks_1.html </li></ul></ul></ul>
  30. 30. User Access Risk <ul><li>Privileged user access </li></ul><ul><ul><li>Who has access to your data?
  31. 31. Who administers the systems?
  32. 32. Governance </li></ul></ul>
  33. 33. Regulatory Compliance Risk <ul><li>You are ultimately responsible for the security and integrity of your own data </li></ul><ul><ul><li>What is in your data?
  34. 34. Do you store sensitive information about others?
  35. 35. Is the supplier subject to external audit in the same way as conventional suppliers of outsourcing solutions? </li></ul></ul>
  36. 36. Data Location Risk <ul><li>You probably have no control of where your data is physically held </li></ul><ul><ul><li>Can you insist that it be held within a certain jurisdiction?
  37. 37. Can the Cloud provider sign up to local privacy requirements on behalf of their customers? </li></ul></ul>
  38. 38. Data Segregation Risk <ul><li>Your data is usually stored in shared environments along with the data of other customers. </li></ul><ul><ul><li>Ask about encryption schemes used and how they are verified
  39. 39. Assess risk of encryption accidents </li><ul><li>Possibility of rendering data unreadable </li></ul></ul></ul>
  40. 40. Risks Associated With Recovery <ul><li>Even with modern equipment disasters can (and do) still happen </li></ul><ul><ul><li>Can the supplier do a complete recovery?
  41. 41. How long will a full recovery take?
  42. 42. Granularity of recovery? </li></ul></ul>
  43. 43. Risks inherent in investigating security breaches and illegal activity <ul><li>Inherent difficulty in investigating illegal activity in shared environments </li></ul><ul><ul><li>To what extent can the supplier support investigative work?
  44. 44. To what extent do you have to account for illegal activity involving your application and/or data? </li></ul></ul>
  45. 45. Risks associated with sustainability <ul><li>Long term viability of supplier </li></ul><ul><ul><li>What happens if the supplier goes bust?
  46. 46. What happens if the supplier is taken over by another company?
  47. 47. How would you get your data back (and port it to another platform) if you needed to? </li></ul></ul>
  48. 48. Technical view
  49. 49. Cloud Computing: Security Standards compliance <ul><li>Credit Card transactions </li></ul><ul><ul><li>Payment Card Industry – PCI compliance </li><ul><li>4 Levels </li></ul></ul></ul><ul><li>Confidential data </li></ul><ul><ul><li>Medical records
  50. 50. Personal financial data </li></ul></ul><ul><li>Securing applications </li></ul>
  51. 51. PCI compliance <ul><li>Level 1 </li></ul><ul><ul><li>Very large businesses and/or those that have been compromised
  52. 52. More than 6 million transactions per year
  53. 53. Systems designed by credit card companies
  54. 54. Annual on-site security audit
  55. 55. Quarterly system perimeter scans </li><ul><li>Probe of network to detect vulnerabilities </li></ul><li>Merchants choose from certified list of service providers </li></ul></ul>
  56. 56. PCI compliance <ul><li>Level 2 </li></ul><ul><ul><li>Merchants processing 1,000,000 to 6,000,000 transactions per year
  57. 57. Annual compliance questionnaire
  58. 58. Quarterly system perimeter scans </li></ul></ul>
  59. 59. PCI compliance <ul><li>Level 3 </li></ul><ul><ul><li>Merchants processing 20,000 to 1,000,000 transactions per year
  60. 60. Annual compliance questionnaire
  61. 61. Quarterly system scans </li></ul></ul>
  62. 62. PCI compliance <ul><li>Level 4 </li></ul><ul><ul><li>Merchants processing less than 20,000 transactions per year
  63. 63. Annual self-assessment questionnaires
  64. 64. Quarterly scans </li></ul></ul>
  65. 65. PCI compliance in the Cloud <ul><li>Basic Level 4 compliance </li></ul><ul><ul><li>Don’t store credit card information </li><ul><li>One-time transactions via web services to a credit card processing gateway </li></ul><li>Can be done inside or outside cloud </li></ul></ul>
  66. 66. PCI compliance in the Cloud <ul><li>Storing credit card information? </li></ul><ul><ul><li>Usually need level-2 compliance </li><ul><li>Not attainable on shared virtualized servers in the cloud </li></ul></ul></ul><ul><li>In-house solution </li></ul><ul><ul><li>Credit card details must be stored outside cloud </li><ul><li>Or on dedicated virtualized environments </li><ul><li>Rackspace and GoGrid </li></ul></ul></ul></ul><ul><li>Third party supplier </li></ul><ul><ul><li>Cloud based provider of billing systems </li><ul><li>Store the credit card data on your behalf and manage any recurring transactions for you </li><ul><li>Zuora or Aria </li></ul></ul></ul></ul>
  67. 67. PCI Compliance in the Cloud Source: http://cloudsecurity.org
  68. 68. Cloud Computing: Securing confidential information <ul><li>Medical records
  69. 69. Personal financial data
  70. 70. Perception of risk is as important as actual risk
  71. 71. Compartmentalise data </li></ul><ul><ul><li>Anonymous data in the cloud
  72. 72. ‘ Root index’ stored outside the cloud
  73. 73. Data in the cloud cannot be related to a particular individual without the ‘root index’. </li></ul></ul>
  74. 74. Cloud Computing: Securing confidential information PATIENT Patient_ID Name Birth_Date Address ADMISSION Patient_ID Admission_Date Ward Consultant TEST Test_Date Specimen_ID Patient_ID Specimen_Type TEST_RESULT Test_Date Specimen_ID Test_ID Result
  75. 75. Cloud Computing: Securing confidential information <ul><li>Typical Hospital Database </li></ul><ul><ul><li>Data is meaningless without the Patient Master Index </li><ul><li>PATIENT Object/Table keyed by PATIENT_ID </li></ul><li>Use of surrogate keys
  76. 76. Anonymization is already used for research data </li></ul></ul><ul><li>Hybrid approaches using public and private cloud infrastructure </li></ul><ul><ul><li>M/Gateway’s M/DB </li><ul><li>Plug compatible with Amazon’s SimpleDB </li></ul></ul></ul>
  77. 77. Obscurity in the Cloud <ul><li>Most attacks on publically accessible infrastructure are against known vulnerabilities
  78. 78. Hide identity of web server and underlying platform </li></ul><ul><ul><li>Use header masking facilities if they are available
  79. 79. Use customized error pages </li></ul></ul>
  80. 80. Securing Applications in the Cloud <ul><li>HTTP Basic authentication </li></ul><ul><ul><li>Supported by all browsers
  81. 81. Client credentials passed to server in the clear
  82. 82. Really only useful for secured (internal) networks </li></ul></ul><ul><li>HTTP digest authentication </li></ul><ul><ul><li>Protection for password
  83. 83. Some compatibility issues with browsers
  84. 84. Still not as strong as authentication over SSL/TLS or Kerberos. </li></ul></ul><ul><li>Both only suitable for guarding against casual attacks in private Clouds </li></ul>
  85. 85. Securing Applications in the Cloud <ul><li>SSL/TLS </li></ul><ul><ul><li>Transport Layer Security (successor to SSL)
  86. 86. Usually authenticates server to a non-authenticated client </li><ul><li>Certificate issued to server.
  87. 87. Client identifies him/herself using a username/password over the secure channel (all communications encrypted). </li></ul><li>Mutual authentication </li><ul><li>Certificate issued to both client and server </li></ul></ul></ul><ul><li>Kerberos
  88. 88. Both suitable for use in public Clouds </li></ul><ul><ul><li>User authentication
  89. 89. Content protection </li></ul></ul>
  90. 90. Coding for the Cloud <ul><li>Client-side JavaScript in web applications </li></ul><ul><ul><li>Ajax techniques
  91. 91. Code can be viewed by the client
  92. 92. Protect against users modifying URLs used in Ajax calls </li></ul></ul>
  93. 93. Storing Data in the Cloud <ul><li>Your own database hosted in the cloud </li></ul><ul><ul><li>Security ‘best practice’ is the same as for any other public facing web application
  94. 94. Be careful with Ajax techniques </li></ul></ul><ul><li>Proprietary Cloud-based data store </li></ul><ul><ul><li>Amazon Web Services: S3, Simple DB
  95. 95. Charged by usage
  96. 96. Be sure to protect ‘access keys’ to data-store! </li><ul><li>AWS Access Key
  97. 97. Be particularly careful with JavaScript
  98. 98. Keys should only be visible to a ‘proxy layer’ mediating between client and server </li></ul></ul></ul>
  99. 99. Conclusion <ul><li>Conventional Web Security
  100. 100. Role for Hybrid Architectures </li></ul><ul><ul><li>E.g. M/DB and Amazon SimpleDB </li></ul></ul><ul><li>Common sense </li></ul>

×