Meetup: http://www.meetup.com/SF-Bitcoin-Devs/events/175021632/
Original slides: http://www.slideshare.net/ukd1/bitcoin-ops-security-primer
####I Recommendations
- Fix Heartbleed immediately, check the blogs of all services you use for updates on their patching process. http://heartbleed.com/
- Use Cloudflare till you can afford your own security operation
- Enable email DKIM/SPF
- Account state graduation - accounts start with minimal priviledges and earn priviledges over time as trust develops
- Publish a clear email policy - will never ask for your uid/pwd, etc
- Lockout policy vs brute force attacks - too many login attempts/t = lockout for T
- Keep OS recent and updated
- Automate provisioning & deployment, immutable infrastructure
- Hire pen-testers
- Have a security program - best templates = Stripe and Coinbase, copy one or both. https://stripe.com/help/security, https://coinbase.com/whitehat
- Transaction & Locking - both Flexcoin & Poloniex hacked due to lack of DB transactions and locking. https://news.ycombinator.com/item?id=7541431
- Use IDS, choice of FOSS or paid proprietary, monitors network and servers https://duckduckgo.com/?q=open+source+intrusion+detection+system, http://www.palantir.com/solutions/cyber/
- Firewall both ways - don't let them in but if get in don't let them out
####II External services
- Verify their SSL certs
- Limit their IPs
- Ex: if using Coinbase to send money, verify you're using their certs and IPs
- Encrypt your backups, breached unencrypted backups = bad
- Test backup restore processes
####III Know Your Customer KYC
- Know their behavior
- Graduated/Progressive account limits
- For abnormal behavior, a manual override your devs can use to enable abnormal behavior should not be possible, opens door to human mistakes in dealing with one-off situations
####IV Educate yourself
- Start with your own stack's security best practices and known vulns https://cve.mitre.org/
- Use secure by default tech whenever possible, ex redis, don't turn off defaults
- Get on OS etc sec mailing lists, seclists for every piece of software you use.
- Staff OPSEC - do not give access to peopwho don't need it, don't give devs access to prod, use deployment system controlled by a SysAdmin instead.
####V Server
- Avoid shared servers, but if must use, AWS best choice, don't go cheap. If you never implement perfect in-house secure systems because your dev team too small, not enough time, then better to use AWS or other reputable 3rd party now than to leave your in-house security in limbo.
- Use SSH key authentication not passwords, rotate keys
- Use Honey Pots in addition to IDS, fake high value targets on network with sensors
- Use firewall, from iptables to physical hardware.
- Do as little as possible, keep your stack as simple as possible, limit services and software whenever possible, don't add extra attack surface when you can avoid it
- Split your services into diff servers. If can't afford full servers, then virtualize with LXC (Docker) or KVM, security on these good now.
- Partitions + noexec + nosuid (Novak presentation)
- Segment apps to diff users too, each user only access its own service
- Remove all packages you do not use
- Disable root, sudo only
- SELinux or Apparmor, don't turn it off, learn to configure
####VI Starting points
- Figure out and fix your highest risk first
- Keep your architecture as simple as possible
####VII Conclusion
- Simpler = better
- See presentatin notes page 50 for further reading
- @rhs
- @rainforestqa
Shared from Google Keep