Truly Secure: The Steps a Security Practitioner Took to Build a Secure Public Cloud
0 likes388 views
The document outlines essential steps to build a secure public cloud, emphasizing the significance of architecture, security practices, and vendor trust. It presents a structured approach including software evaluation, installation monitoring, and thorough security testing to ensure a resilient infrastructure. Additionally, it highlights the importance of continuous learning and improvement through iterative practices and maintaining oversight on security measures.
![Stay in Touch Email – [email_address] Twitter - @johnlkinsella](https://image.slidesharecdn.com/csa11jkinsella-111118170535-phpapp01/85/Truly-Secure-The-Steps-a-Security-Practitioner-Took-to-Build-a-Secure-Public-Cloud-44-320.jpg)
Truly Secure: The Steps a Security Practitioner Took to Build a Secure Public Cloud
- 1. Truly Secure: The Steps a Security Practitioner Took to Build a Secure Public Cloud Session #8 Wednesday, November 16, 2011 10:45am John Kinsella Founder, Stratosec
- 2. Intro BoD, co-founder – Silicon Valley Chapter, CSA Co-chair, CSA Portability and Application Security Founder, Stratosec Secure IaaS Large background in information security and datacenter operations
- 3. Overview Why Architecture Building Operations
- 4. Ground rules Focused around IaaS, but ideas good elsewhere No finger-pointing at specific brands
- 5. Why this talk? Cloud management platforms: Relatively new software From relatively new software teams Frequently relatively immature engineering standards
- 6. Focus of this talk
- 7. Why?
- 9. Architecture & Design Software Worries Benefits Pieces
- 10. Focus of this talk
- 11. What is a Secure Public Cloud? What are people worried about? What are we giving them for their money?
- 12. Worries “ Standard” issues: Data security Resource availability Bad neighbors
- 13. Benefits “ Secure clouds” provide “ Standard” cloud benefits, plus… Data security (encryption and integrity) Heightened security posture
- 14. Required functionality “ Basic” pieces: Highly available infrastructure (HVM+Net+Storage) Security pieces: Encryption Intrusion detection Security monitoring
- 15. Encryption Several forms to choose from: Database encryption SAN encryption Pass-through device
- 16. IDS With all these moving parts, you really need multiple layers of IDS: Network IDS Host-based IDS WAF
- 17. Security Monitoring Centralized log management is a must. As the cloud grows, the amount of data to process will be huge. You need a system with relatively low false-positive rate.
- 18. Building Practice Trust Test Review Repeat
- 19. Building a secure cloud Setup hardware – lab first, if possible Select software Trial period Move to production
- 20. Practice Makes Perfect If you do this right, you will build, tear down, and rebuild this cloud several times as you learn from your (and your vendors) mistakes.
- 21. Trust Who do you trust to build your secure cloud? Yourself Your staff 3 rd party security/cloud professionals Vendor support staff?
- 22. Trust From a vendor’s website:
- 23. Setup Basics Harden Hypervisor OS Consider a automation suite
- 24. Selecting a Cloud Platform Create a list of possible packages Look for security features in each Legwork – how have the maintainers treated security? Pick one or two to test out Trial period is mandatory .
- 25. Trial Period Incorrect: Get software Install software Test functionality
- 26. Trial Period Incorrect: Get software Install software Test functionality Correct: Get software Review software Install while monitoring Understand results of installation Test functionality Test security … Profit
- 27. Review Software If you’re lucky, your chosen software is either open-source or is at least human-readable. Some things to look at: Installer scripts Startup scripts Default configurations Cronjobs or other automated processes Main application Inter-system connectivity
- 28. Me? Code review? Basic code review doesn’t require huge expertise Complete, thorough review vs. targeted review Not suggesting using commercial tools (Fortify, Ounce, Veracode) Several quick “ greps ” will disclose much info
- 29. Review Software Ask: What does this code do to my already hardened system? Are firewalls disabled, or security measures removed? What new software (and potential vulnerabilities) does it install? What exactly is the code doing? Is the application more trusting than it should be? Where was the developer lazy?
- 30. Review Software Keywords to search for: ipconfig, ifconfig mkdir, rm, chown, chmod, exec service rpm, yum, apt sysconfig, sysctl, reboot mysql, pgsql
- 31. Code Review email sent to vendor after code review:
- 32. Monitored Installation The installation environment is yours – control it. Capture a log of the installation process Make sure IDS capture any changes made during installation With your initial security configuration, the initial installation will probably not be successful.
- 33. Review Gathered Intelligence Review the results of the install Look for errors during installation Some can be fixed by loosening security controls Some must be fixed by vendor
- 34. Test Functionality Marketing is wonderful. So what does this thing really do for me?
- 35. Test Security Standard security testing scenario: The app is insecure, question is if you have enough resources to find the weakness. Low-hanging fruit: SQL Injection, XSS, lack of encryption, default values Higher fruit: buffer overflows, non-standard (read: “bad”) encryption, bad resource handling
- 36. Test Security Network scan – Do a thorough scan, not just looking for known ports. Make sure you know where the application is listening, and what your firewall is allowing. Vulnerability Scanner – applications that leverage open-source packages may come with known vulnerabilities Don’t just perform network-based tests – test from on the box as well. Fuzzing – when you find a particular input that looks like it was developed in-house without common libraries, throw a fuzzer at it.
- 37. Test Security
- 38. Sound familiar? I’ve basically described a Secure Software Development Lifecycle (Secure SDLC) As your organization grows in size, you’ll want to adopt several standardized processes: Security reviews Test, build, and release processes
- 39. Operations
- 40. Operations – Who Do You Trust? How do you keep your new cloud running smoothly? Monitor security and performance Keep systems up-to-date Troubleshoot issues as they arise
- 41. Operations – Who Do You Trust?
- 42. Operations – Who Do You Trust?
- 43. Follow a SSDLC (design, build, test, and run with security in mind) Be confident in your security – have statistics and test results to confirm your state of security. Do not trust vendors Summary
- 44. Stay in Touch Email – [email_address] Twitter - @johnlkinsella
Editor's Notes
- #2: TITLE MIS Training Institute Section # - Page XXXXXX XXX ©
- #5: Ideas for IaaS, but as Phil Wainewright mentioned this week, “every private cloud has a public face” TITLE MIS Training Institute Section # - Page XXXXXX XXX ©
- #8: Average age of these platforms is less than 2 years of age. TITLE MIS Training Institute Section # - Page XXXXXX XXX ©
- #14: “ separation” of customers TITLE MIS Training Institute Section # - Page XXXXXX XXX ©
- #16: Pass-through device like CipherCloud TITLE MIS Training Institute Section # - Page XXXXXX XXX ©
- #24: What does harden mean? Tighten down your firewalls, only install necessary packages, use SELinux if you’re really brave… TITLE MIS Training Institute Section # - Page XXXXXX XXX ©
- #37: Fuzzer examples: Peachfuzz, SPIKE, WebFuzzer, Metasploit… TITLE MIS Training Institute Section # - Page XXXXXX XXX ©
- #44: TITLE MIS Training Institute Section # - Page XXXXXX XXX ©