Downloaded 11 times
Uploaded byOleg Podsechin
Staying safe in the cloud
This document discusses various ways to stay safe in the cloud, including ensuring availability, reliability, and privacy. It outlines potential attack vectors like social engineering, packet sniffing, and zero-day exploits. Some recommended countermeasures include encrypted drives, strong passwords, two-factor authentication, and security audits. The document also discusses trade-offs between self-reliance and reliability as well as security and convenience. It notes that while security is important, users often don't care if a service gets hacked and every service will likely experience a breach at some point.
Staying safe in the cloud
- 1. Staying Safe inthe Cloud
- 2.
- 3.
- 6. define: security ● availability ○no access ● reliability ○ data loss ● privacy ○ data leak
- 7. Availability ● Pingdom ● Where’sit Up? ● StatusPage.io ○ status.myservice.com: ~ 10% ● Hosting & Infrastructure ○ CDNs like CloudFlare - test with Blitz etc. ○ DaaS like AWS RDS, MongoHQ etc. ○ deployment, e.g. NPM ○ third party JS, tag management e.g. GTM ○ DDOS with botnets, HTTPX
- 9. Reliability ● Funding orlack thereof, business model ○ or corporate strategy, think Google Reader, G+ ● PEBKAC ○ Google Docs, Yammer ● API availability ~ data backup an option ○ programmableweb.com ○ Kimono ● Backupify, Import2
- 10. Privacy ● Third partyJS, GA has 20M accounts ○ BuiltWith ● Retargeting cookies ● Email/IP to user info on social media ○ Rapleaf, Rapportive ○ Intercom ○ FOAF ● FastMail, Minerva Fabric ○ PGP
- 11. Attack Vectors ● Socialengineering, war driving, sniping, drones? ○ Apple Amazon hack ● Rootkits, keyloggers ○ Vodafone Greece example (pre NSA) ● Packet sniffing, port scanning ● 0 day exploits, exploit marketplaces ○ WebGL, Java, Rails, OpenSSL/Heartbleed ● DNS, SSL intercept ○ compromised rootcerts ○ Arab Spring example
- 16. Attack Vectors ● Infrastructureproviders ○ HDDs reused ○ Internal sniffing, e.g. MongoDB ○ OSS clients libs not audited, Nodetime example ● Phishing mails ● Cross site attacks: XSS, CSRF ● Malicious extensions: e.g. Window Resizer ● OAuth, third party app access ○ ~60% use Google for login ● etc. etc.
- 19. Countermeasures ● Encrypted laptopdrives ● Secure passwords ○ LastPass or PwdHash ● Two Factor Authentication 2FA ○ Not enforced by most ● Suspicious activity detection ● Access logs ○ per user audit trail?
- 20. Preemption ● Security audits ●“Honeypots” ● Production/Staging divide ● Bug bounty programs
- 22. Politics: NSA, etc. ●Hosting outside of US by a non-US legal entity is a competitive advantage ○ e.g. Upcloud, younited ○ caveat: traffic goes via Sweden ● How many SaaS companies from Estonia? ○ Sportlyzer ○ Weekdone ○ GoWorkaBit ○ InventoryAPI
- 24. Shadow IT ● BringYour Own Device (BYOD) ● Bring Your Own Service (BYOS) ● Most companies don’t know what software their employees use ○ … and don’t want to know ● Shared accounts ○ Bitium, Meldium
- 26. Case Study: StartHQ ●first contact: ○ password reset mails ○ access log monitoring ○ break in ○ disable /admin ○ apply fix ● two weeks later: ○ second break in ○ mail sent to all @starthq.com ○ apply second fix, more attempts, no more breakins
- 27.
- 28. Trade-offs ● Self Reliancevs. Reliability ○ Self host MongoDB or go with MongoHQ ○ Speed and time to market critical ● Security vs. Convenience?
- 29. Reality ● Everyone getshacked ○ Atlassian story ● Users largely don’t care ● Case in point: StartHQ extension ○ see video
- 30. Resources Security Engineering byRoss Anderson Light Blue Touchpaper blog
- 31.
- 32. Resources OWASP Top 10Project Homakov blog
- 33.