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.

1. Staying Safe in the Cloud

2. /whois me

3. helsinkijs.org

6. define: security
● availability
○ no access
● reliability
○ data loss
● privacy
○ data leak

7. Availability
● Pingdom
● Where’s it 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 or lack 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 party JS, 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
● Social engineering, 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
● Infrastructure providers
○ 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 laptop drives
● 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
● Bring Your 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. Case Study: Buffer

28. Trade-offs
● Self Reliance vs. Reliability
○ Self host MongoDB or go with MongoHQ
○ Speed and time to market critical
● Security vs. Convenience?

29. Reality
● Everyone gets hacked
○ Atlassian story
● Users largely don’t care
● Case in point: StartHQ extension
○ see video

30. Resources
Security Engineering by Ross Anderson
Light Blue Touchpaper blog

31. Resources
Chaos Computer Club TV

32. Resources
OWASP Top 10 Project
Homakov blog

33. Thank you!
@olegpodsechin