3. PRINCIPLES
1. Reduce attack surface of the cloud environment
2. Address the scenario of compromised employees
3. Restrict points of access down to a small number of assets
4. Audit employee access and changes to the environment
5. Take advantage of the benefits of cloud computing
4. CONSTRAINTS
• Cloud Provider Variations
• Program Maturity & Your Roadmap
• Build vs. Buy
• Your Specific Industry
6. WHO IS RESPONSIBLE?
• Security Operations Teams (SecOps)
• Product/Application Security Teams (Service or Secure Engineering Models)
• Engineering and/or DevOps Teams
• Tools Teams (Owners of CI Tools, Deployment Tools, Asset Visibility Tools, Etc. )
• Operations Teams (Product Responsibilities)
• Information Technology (IT) Teams (Corporate Network Responsibilities)
• Incident Response (IR) Teams
7. WHAT DO CLOUD DEPLOYMENTS
LOOK LIKE?
• Agile Development Process
• Continuous Integration (CI) tools and deployment
pipeline tools
• Frequent deployments
• Micro services supported by persistent data store
• Separate staging and production environments
• Scaling based on load/demand
8. WHAT DO CLOUD DEPLOYMENTS
LOOK LIKE?
• Monitoring tracks environmental health
• Agents installed on instances
• Traffic control for instances
• Emergency rollbacks to a sane environment
• Logs streamed off instances to backend
• Perfect, or near perfect, asset visibility
9. HOW DO ATTACKERS TARGET THESE
TYPES OF ENVIRONMENTS?
• Drive-by attackers will continue to
assault your gates with bananas
• Same defensive measures as standard
in industry
• But for the sophisticated attacker, it is
far more interesting…
10. HOW DO ATTACKERS TARGET THESE
TYPES OF ENVIRONMENTS?
• Employees are the best target to grab
provider account credentials
• Know your deployment model and how
to achieve persistence
• Take advantage of historical
weaknesses in cloud environments
• Target systems that may be confused
deputies
11. CI TOOLS
• Involvement in the development
process
• Third party tool integration
• Custom security tool integration
• Answering questions about the product
Developers
CI Tools
Deployment
Tool
12. DEPLOYMENT TOOLS
• Delegate for Account Credentials
• Emergency Patching
• Business Continuity
• The tool handles the sensitive data
(though may not store it): certificates,
secrets, keys, etc.
14. ASSET VISIBILITY
• Provider APIs give visibility into the environment
• Real-time awareness of the environment
• Know what the outside sees and can touch, knows everything about the internal
environment
• Security toolchains driven by asset tools
• Scanning Depth
• Tool Configurations
• Asset Configuration
15. MICROSERVICE MODEL
• Compact code bases
• Lower frequency of changes
• Security investment strategies
• Who can play with the turtle?
• Monitoring product behavior…
16. LOGGING & AUDITING
• All tools provide valuable data for potential security events
• Logs driven off instance ASAP
• Consider what has been lost, and how it will be replaced
• In house tools
• Security events selected on their confidence/”true positive” issues
• Identify the differences in what is expected: this is stepping outside the security posture
• Identify the anomaly in the environment: this could be an attacker
17. SEGMENTATION
• External Segmentation
• Isolate the Backend
• Allow access through an ”edge”
• Regular verification
• Regular security testing
• Regular code audits
• Cautionary Forensics
18. SEGMENTATION
• Internal Segmentation
• Isolate Employees
• Isolate Sensitive Data
• Isolate Applications
• Regular monitoring to determine
deviance from the expected
configuration
• Multiple cloud providers
19. SCALING
• Challenges to attacker persistence
• Impact on DDoS
• Impact on purchased solutions
• Not all licensing models are amendable to being spun up on demand
• A lot of gaps for security tools we used to consider traditional…
• …but providers are starting to provide equivalents and obtain compliance
