Open stack security emea launch


Published on

Published in: Technology
1 Like
  • Be the first to comment

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

No notes for slide
  • I have 30 minutes for a 2 hour talk, so I’ll cover this at a high level, and I’ll make myself available for more detailed questions afterwards.
  • It’s not an “if” – it’s a “when”
  • 80% of all security attacks come from current or former employees or contractors.Assume every host in your network is or will be compromised, and plan accordingly.
  • (splunk, syslog-ng)
  • Open stack security emea launch

    1. 1. OpenStack Security<br />A Primer<br />
    2. 2. Me: Joshua McKenty<br />Twitter: @jmckenty<br />Email:<br />Former Chief Architect, NASA Nebula<br />Founding Member, OpenStack<br />OpenStack Project Policy Board<br />
    3. 3. “If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.” – Bruce Schneier<br />
    4. 4.
    5. 5. The Three Pillars of Security<br />
    6. 6. “Bonus” Security Pillar<br />Forensics<br />
    7. 7. Real Security<br />Assume everything goes wrong, even impossible things.<br />
    8. 8. FIPS 199 Definition:<br />Confidentiality<br />Integrity<br />Availability<br />Defining Security<br />
    9. 9. Defining Vulnerability<br />
    10. 10. Build on “Shared Nothing” to achieve “Trust No One”<br />Also known as “Defense in Depth”<br />AUTOMATE EVERYTHING<br />“Fat Fingers” == Plausible Deniability<br />Automated == non-repudiable change control <br />Build to the OSI 7-layer model<br />
    11. 11. Layer 1<br />
    12. 12. Lock your doors<br />Do your background checks<br />Use separate physical networks for admin<br />Network model and management<br />Use RFC 1918 address space when appropriate<br />Use VLANs if necessary<br />Firewall every machine (ebtables, iptables)<br />Border firewalls (port and protocol level)<br />Layer 1, 2 and 3<br />
    13. 13. Never assume it’s bilateral<br />
    14. 14. Control system access<br />Best case: no host-based shell access AT ALL.<br />Second-best: federated AUTH with 2-factor, keys only<br />Worstcase: Host-level root login with passwords<br />Run IDS – on hosts and guests<br />Scan Continuously – hosts and guests, on all networks<br />Proactively defend – Fail2Ban, etc. ( F2B-a-a-S)<br />Layer 4, 5, 6 and 7<br />
    15. 15. Don't trust the hypervisor (TXT / TPM)<br />Conversely, don't trust the VM (blue-pill exploits, etc.)<br />Host-based FW within the VM (CloudPassage "Halo")<br />Access-control for VMs – same approaches apply (Auth-as-a-Service)<br />Layer ‘V’<br />
    16. 16. “Proof” and Policy<br />In God We Trust – All Others, Bring Data.<br />
    17. 17.
    18. 18. Classic best practices – redundant, off-site log servers<br />Log aggregation and analysis / event detection<br />Logging-as-a-Service<br />Log early, log often<br />
    19. 19. Make and verify your assertions<br />(Coming soon…)<br />CloudAudit<br />
    20. 20. Did you remember to delete his account?<br />
    21. 21. Security Theatre<br />“Given enough hand-waving, all systems are secure.”<br />
    22. 22.
    23. 23. Crypto is useless – if keys are stored with the data<br />Private networks are useless – if doors aren’t locked<br />Certification only proves that you’re doing, what you said you were going to do. You can still be wrong.<br />Forget “Trust, but verify”. Just don’t trust.<br />Don’t get confused!<br />
    24. 24. Bonus: Forensics<br />It’s not an “If” – it’s a “When”<br />
    25. 25. Have a chaos-monkey of compromise<br />Can you perform forensics and remediation, without impacting other users of your cloud?<br />Spanning ports and extra storage<br />“Graveyard” for recently deleted images, instances<br />Bonus Section: Forensics<br />
    26. 26. What’s in the CloudPipe?<br />“We can only see a short distance ahead, but we can see plenty there that needs to be done.” – Alan Turing<br />
    27. 27. The Machine<br />Aka “Sneaky Monkey”<br />Continuous Integration of penetration and vulnerability testing.<br />
    28. 28. We’re doing “stuff”<br />No… really.<br />Hardening<br />
    29. 29. Outfoxing the fox<br />Intel is working with many companies within OpenStack, including Piston.<br />Trusted Execution<br />
    30. 30. Questions?<br />
    31. 31. Matt Linton – Nebula CSO<br />Jesse Andrews – AnsoLabs Founder<br />Soo Choi – 7120.7 Nazi<br />Matt Chew- Spence – FIPS 199 Guru<br />Keith Shackleford and James Williams<br />Chris Kemp<br />Bobby Cates, Dave Swagger, E. Lopez, Grace De Leon, Guy with Gun #1, Guy with Gun #2…<br />Credits<br />