Security Challenges in Cloud Integration - Cloud Security Alliance, Austin Chapter


Published on

Security Challenges in Cloud Integration, a presentation given at the Cloud Security Alliance, Austin Chapter meeting held on February 2, 2012.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Security Challenges in Cloud Integration - Cloud Security Alliance, Austin Chapter

  1. 1. Security Challenges inCloud Integration Pervasive DataCloud21
  2. 2. Pervasive SoftwareGlobal Software Company • Tens of thousands of users across the globe • Operations in Americas, EMEA, Asia • ~250 employeesStrong Financials • $49 million revenue (trailing 12-month) • 43 consecutive quarters of profitability • $40 million in the bank • 22 consecutive quarters of active share buyback • NASDAQ: PVSW since 1997Leader in Data Innovation • 24% of top-line revenue re-invested in R&D • Software to manage, integrate and analyze data, in the cloud or on-premises, throughout the entire data lifecycle2
  3. 3. Jason WagnerPlatform ManagerPervasive DataCloud2• Management of DataCloud2 architecture, engineering, and operations teams• 11 years experience in system administration, web services and integration architectures• Previously: – CRM and Business Intelligence Platforms at Roche Tissue Diagnostics – Integration Solutions Architecture at Pervasive Software3
  4. 4. Pervasive DataCloud2 • Integration Platform as a Service (iPaaS) • Hosted Design Service to build and test integration connectivity and workflows • Management Console and API access to deploy, schedule, and execute integration jobs • Elastic job execution service to scale up and down with customer needs and blackbox their own SaaS and on-premise integration applications4
  5. 5. Pervasive DataCloud2 DataCloud2 provides a secure and intuitive way to Design, Deploy and Manage both SaaS to SaaS or SaaS to On- premise SaaS ISV’s SI Enterprise IT5
  6. 6. SaaS<->SaaS Integration Cloud ApplicationLegendAdministration &Configuration Integration Developers(No Customer Data) & End UsersCustomer Data Flow6
  7. 7. SaaS<->On-Premise Integration Cloud ApplicationLegendAdministration &Configuration(No Customer Data)Customer Data Flow Integration Developers & End Users7
  8. 8. Industry-Leading Connectivity8
  9. 9. Our  “Security”  Mission 1. Protect Customers and Infrastructure from External Threats 2. Protect Customers and Infrastructure from Internal Threats 3. Protect Customers and Infrastructure from Each Other9
  10. 10. Protection from External Threats • Strict Firewall Rules • OS Event Monitoring • API Usage Monitoring • Vulnerability Scanning • Breach Protocol • Disaster Recovery Plan10
  11. 11. Strict Firewall Rules • Make sure firewall changes are not taken lightly – challenging for us because our customers expect to connect to MANY different endpoints • Minimize the number of cloud boxes that are exposed – continual audit of WHY? REALLY? • Elastically allocated resources are the most susceptible, so we are very cautious to lock down inbound ports on these – even from our own internal network access, e.g. Jump Servers11
  12. 12. Strict Firewall Rules(layered security groups) Elastic Load Core Web and Job Scheduling and Elastic Balancer Application Servers Queuing Service Worker Nodes (Job Processors) 1 2 3 4 5 6 Job Data Execution Storage12
  13. 13. Strict Firewall Rules (protecting customer on-prem resources) Deploy Monitor Customers with Onramp on-premise apps Framework ERP/CRM Load Database Analyze Data prep Data collect Aggregate Schedule Join Partner mgmt Message Q Transform Reformat Match  Validate Record linkage Profile Reports Firewall13
  14. 14. OS Event Monitoring • Collect and monitor OS events for any changes to permissions or alerts • Some of the system events we are interested in: – Failed login attempts – Successful login attempts – User access changes – Group access changes14
  15. 15. API Usage Monitoring • Collect and monitor API usage for many kinds of statistics • Some of the statistics we are interested in: – Failed login attempts – Failed object access attempts – Activity volume by operation – Activity volume by user15
  16. 16. Other Types of Monitoring • Collect and monitor other types of statistics • Some of the statistics we are interested in: – Web page reads and write attempts – Database activity, SQL injection – URL modification, XSS16
  17. 17. Vulnerability Scanning • Regular intrusive and DoS attack simulations during maintenance windows • Include scans as part of SDLC and any significant change to staging or production environments • We use several popular services for external scans,  as  well  as  our  own  “DoS/Brute  Agent”17
  18. 18. Breach Protocol • Have breach protocol well-documented and easy to find to prevent knee-jerk or panic reactions • Suspected/confirmed breach (red flag) – Quarantine/Triage/Investigation – Notification/Transparency/Lessons Learned • Limiting breach exposure – Data Encryption – Monitoring/Auditing – Contractual Language18
  19. 19. Disaster Recovery Plan • It is important to be well-documented and spelled- out contractually (whatever the plan is) • Disaster recovery is more than just geographic catastrophe and redundancy, but also: – How do you recover from significant outage caused by malicious activity? – How do you recover from a vendor outage? Amazon? Rackspace? – How do you respond if critical/confidential data is lost or compromised?19
  20. 20. Protection from Internal Threats • Sometimes Well-intentioned • Operational Run Book • Periodic and Spot Check Audits • Access Activation/Deactivation Protocols • Segregation of Duties/Change Control • Shared Passwords20
  21. 21. Operational Run Book • Regular, weekly reports from all security related tools: – Cloud Firewall Configurations – OS and API Monitoring Logs – IDS/IPS Reports – Availability and Performance Metrics – Deployment/Patch/Source CM Reports – Incident Reports – Vulnerability Scan Report • Good to have when you are auditor or auditee21
  22. 22. Internal Audits • Three types of audits to consider: Scheduled, event-driven, and random spot check • Some of the things we are interested in: – Cloud Firewall changes reconcile with approved change log – User permissions reconcile with approved change log – Approved change log is properly documented (WHY? REALLY?) – Customer  usage  rates  fall  within  “expected”  range22
  23. 23. Access Activation/DeactivationProtocol • Work closely with Corporate IT and HR to document roles, functions, and who has access to what… • Build matrices of access/permission changes based on role and procedures that must take place whenever someone leaves or joins the team/company • Don’t  forget  to  account  for  contractors….23
  24. 24. Segregation of Duties/CM • Identify conflicts between engineering and operations – Formal escalation process – Protocol for engineering access to production systems • Enforce change control for security sensitive changes – Cloud Firewall modifications – User or group access privileges – Any kind of software or hardware patch in production24
  25. 25. Shared Keys/Passwords • AVOID, but make sure shared password reset events are well-known/documented (Access Activation/Deactivation Protocol) • There are tools to assist – We have had success with LastPass “secretly”  sharing  passwords,  i.e.   the end user does not know the password and it can be revoked from their LastPass account at any time25
  26. 26. Protecting Our Customers andInfrastructure from Each Other • Service and Data Availability • Multi-Tenancy on Elastic Resources • Handling Agents and Clients • Alerts and Error Reporting • Contract Language26
  27. 27. Service and Data Availability • Public Trust Site – We try to be as transparent as possible with our external monitors, without actually publishing the exact checks/procedures • Internally make sure we have a pulse on real time volumes – if in danger of NOT scaling, that could be a security risk to us and our customers • Data Integrity – this can get complex when you start dealing with highly scalable data stores that may not be inherently relational27
  28. 28. Industry-Leading Connectivity28
  29. 29. Multi-Tenancy on Elastic Resources • This is a challenge for us due to the power and flexibility of our product – we have to limit cloud functionality vs. on-premise use • We encrypt any kind of identifying information – that we know about • We  spend  a  lot  of  resources  “cleaning”  up  after   jobs are executed – we have to plan for some loss of concurrency and efficiency because of the continual  need  to  prop  up  and  tear  down…29
  30. 30. Agents and Clients • We our own managed clients called agents for on-premise connectivity, which typically are connecting and communicating to the “integrating”  apps  as  well  as  DataCloud2 • Adds another dimension to what we have to track in terms of not only users that are connecting, but WHAT and WHERE are they connecting from? • What about custom DataCloud2 clients built by customers?30
  31. 31. Alerts and Error Reporting • Challenge for us is that our customers have all kinds of different projects and metrics they are interested in • How are customers notified of different events they may be interested in? • It is possible that integration logs may have confidential information – especially if they are customized by the user/developer (see contract)31
  32. 32. Contract Language • How we behave is well-documented: – Breach Notification Policy – Backup Policy and Remedies – Data Redundancy Policy – Service Redundancy Policy – History and Log Archival • Customer data storage policy – Types Allowed, HIPAA? – How do you audit that your customers are compliant? – Encrypt all? Or just what is necessary? (see contract)32
  33. 33. Security Challenges inCloud Integration The End Questions?33