Embed Size (px)
DESCRIPTION
This "mini" version of my CSA Congress talk about building a secure cloud was given at the San Francisco Cloud Security Meetup in November, 2011.I got some great feedback while giving this talk, and will be applying it to an updated version of this deck which will be released during the CSA Congress, November 15th and 16th 2011.
Citation preview
Building a Secure CloudSF Cloud Security Meetup
11/3/0211
Slide 2
Intro
Slide 3
Why?
Slide 4
Why?
From http://www.ece.cmu.edu/~koopman/des_s99/sw_reliability/
Slide 5
Required functionality
“Basic” pieces:
Highly available infrastructure (HVM+Net+Storage)
Security pieces:
Encryption
Intrusion detection
Security monitoring
Slide 6
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.
Slide 7
Building a secure cloud
Setup hardware – lab first, if possible
Select software
Trial period
Move to production
Slide 8
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.
Slide 9
Who Do You Trust?
Who do you trust to build your secure cloud?
Yourself
Your staff
3rd party security/cloud professionals
Vendor support staff?
Slide 10
Who Do You Trust
From a vendor’s website:
Slide 11
Who Do You Trust?
Slide 12
Setup Basics
Harden Hypervisor OS
Layer Security
Use an automation suite
Slide 13
Selecting a Cloud Platform
Create a list of possible packages
Look for security features in each
Legwork – how have the maintainers treated security?
Pick two or three to test out
Trial period is mandatory.
Slide 14
Trial Period
Incorrect:Get softwareInstall softwareTest functionality
Slide 15
Trial Period
Incorrect:Get softwareInstall softwareTest functionality
Correct:Get softwareReview softwareInstall while monitoringUnderstand results of installationTest functionalityTest security…Profit
Slide 16
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
Slide 17
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?
Slide 18
Code Review
Slide 19
Monitor The 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.
Slide 20
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
Slide 21
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
Sweeter fruit: buffer overflows, non-standard (read: “bad”) encryption, bad resource handling
Do some threat modeling
Slide 22
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.
Slide 23
Test Security
Slide 24
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
Slide 25
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
Slide 26
Operations – Who Do You Trust?
Slide 27
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
