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