Downloaded 41 times
Uploaded byShannon Lietz
A Throwaway Deck for Cloud Security Essentials 2.0 delivered at RSA 2016
The document outlines essential principles of cloud security, emphasizing the fundamental differences between cloud environments and traditional datacenters. Key topics include the importance of shared responsibility, the necessity of multi-factor authentication, and the need for automation and instrumentation in security protocols. It advocates for a proactive security mindset through experimentation and community involvement in developing cloud-native security strategies.
More Related Content
Similar to A Throwaway Deck for Cloud Security Essentials 2.0 delivered at RSA 2016
A Throwaway Deck for Cloud Security Essentials 2.0 delivered at RSA 2016
- 1. CLOUD SECURITY ESSENTIALS 2.0 CRAWL.WALK. RUN. Javier Godinez Principal DevSecOps Architect Intuit Shannon LIetz Director, DevSecOps & Security Eng Intuit @devsecops
- 2.
- 3. Uh… where dothese go? 3
- 4.
- 5. Let’s switch somethings around… 5 Data Center Network Servers Virtualization Operations Platforms Buyer Identifier Cloud Account(s) Virtual IP Addresses Containerization Appliances Storage Security Features Applications Ephemeral Instances Scale on Demand IAAS, PAAS, SAAS Resource Testing Built-In Security Long-Term Contracts Partner Marketplaces Slow-ish Decisions Experiments
- 6. The Basic CloudModel 6 CloudProviderNetwork Backbone Backbone Cloud Platform (Orchestration) Network Compute Storage Internet CloudAccount(s) Load Balancers Compute Instances VPCs Block Storage Object Storage Relational Databases NoSQL Databases Containers Content Acceleration Messaging Email Utilities Key Management API/Templates Certificate Management Partner Platform
- 7.
- 8.
- 9. Developers have lotsof options… 9
- 10. And Attackers alsohave lots of options… 10
- 11.
- 12. This collaborative effortcan help DevOps-led projects make IT operational metrics 100 times better, and in so doing offers “an evolutionary fork in the road” which could lead to the “end of security as we know it,” added Joshua Corman – founder of Rugged DevOps and I am the Cavalry. DevOps brings mega-change! 12 http://www.infosecurity-magazine.com/news/infosec15-devops-end-of-security … And maybe that’s a good thing!
- 13. Top 5 CloudSecurity Principles 2.0 • The Cloud is not a Datacenter. • Reduce blast radius; play the odds. • Encryption is inconvenient. • Speed & Ease is both Friend & Foe. • Protection is ideal; Detection is a must! 13
- 14.
- 15. The Cloud isnot a Datacenter. 15
- 16. Direct Connections/VPNs toClouds are evil! 16 CloudProviderNetwork DataCenter PUBLIC SUBNET APP DATABASE DATABASE APP PUBLIC SUBNET VPN Cloud Web Console API Credentials “NEW” BOUNDARY HAS ALL THE WEAKNESSES OF BOTH AND MIXES TWO DIFFERENT SECURITY MODELS! Remote Access PRIVATE SOFTWARE VPN MANAGED VPN 10.0.0.0/8 Connected & Routable? No IDS? What do you mean the IP could change? Tags? Security Groups? SDE?
- 17. Host-Based Controls 17 • SharedResponsibility and Cloud require host-based controls. • Instrumentation is everything! • Fine-grained controls require more scrutiny and bigger big data analysis. CloudProviderNetwork InstanceInstance Tested machine image… Tested instances... Tested roles... Tested passwords... New instance created… Instance 12345 changed… User ABC accessed Instance 12345... B
- 18. Lights out… 18 • Lightsout datacenters have always been a desired nirvana. • Automation is required to stack and replace cloud workloads. • Cloud security benefits are derived from lights out… • Automation & Instrumentation • Ephemeral Bastions • Drift Management • Security Testing Tested machine image… Tested instances... Tested roles... Tested passwords... New instance created… Instance 12345 changed… User ABC accessed Instance 12345... B CloudProviderNetwork Bastion Instance Instance
- 19. Long live APIs… 19 •Everything in the cloud should be an API, even Security… • Protocols that are not cloudy should not span across environments. • If you wouldn’t put it on the Internet then you should put an API and Authentication in front of it: • Messaging • Databases • File Transfers • Logging CloudProviderNetwork Tested machine image… Tested instances... Tested roles... Tested passwords... New instance created… Instance 12345 changed… User ABC accessed Instance 12345... B User Routing Data Replication Application Gateway File Transfers Log Sharing Messaging My API
- 20.
- 21. Blast Radius isa real thing… 21
- 22. Beware of Orchestrators… 22 •Orchestration creates blast radius because it centralizes the deployment/security for cloud workloads. • Tools that act on behalf usually require credentials and create blindspots. • Non-native tools require specialized skills and make it difficult to gain context on what the right behavior should be. Cloud Orchestration Platform CloudProviderNetwork A B C CloudAccount CloudAccount CloudAccount secrets What’s normal?
- 23. Account Sharding isa new control! 23 • Splitting cloud workloads into many accounts has a benefit. • Accounts should contain less than 100% of a cloud workload. • Works well with APIs; works dismal with forklifts. • What is your appetite for risk? Cloud Workload Templates CloudProviderNetwork 33 % 33 % 33 % CloudAccount CloudAccount CloudAccount attacker
- 24. MFA is aMUST! 24 • Passwords don’t work. • Passwords aren’t enough to protect infrastructure. • Use MFA to protect User accounts and API credentials used by Humans. • On some cloud platforms it is possible to make roles work only when MFA is provided and for certain actions to require MFA. 123456 Implement cloud template… API Credentials accepted... Please input your MFA token: XXXXXX (123456) Cloud stack 123 has been implemented.
- 25. 50 % Cloud DisasterRecovery is a different animal… 25 • Regional recovery is not enough to cover security woes. • Security events can quickly escalate to disasters. • Got a disaster recovery team? • Multi-Account strategies with separation of duties can help. • Don’t hard code if you can help it. • Encryption is inconvenient, but necessary… Cloud Workload Templates CloudProviderNetwork 50 % 50 % CloudAccount CloudAccount Disaster Templates 50 % CloudAccounts
- 26.
- 27. Encryption is anecessary evil… • It helps with Safe Harbor. • It helps with SQL Injection. • It helps with Data Ownership. • It helps with Privacy. It’s not a silver bullet… 27 CloudProviderNetwork CloudAccount CloudAccount CloudAccount Instance Secrets Management Key Management & Encryption App DB Disk Managed Service
- 28. So much inconvenience •It can limit scale and it may narrow design options. • Scalable Key Management is really hard in the cloud. • Inconvenience commonly comes from blue/green changes, dynamic environment & sharing secrets for auto-scale. 28 Instance Secrets Management Disk Instance Disk Instance Disk Instance Disk Instance Disk Instance Disk Instance Disk Instance Disk Instance Disk Instance Disk Instance Disk APP APP DB DB CloudAccount CloudAccount Phew I’m exhausted
- 29. Overcoming Inconvenience • Usebuilt-in transparent encryption when possible. • Use native cloud key management and encryption when available. • Develop back up strategies for keys and secrets. • Apply App Level Encryption to help with SQL Injection and preserving Safe Harbor. • Use APIs to exchange data and rotate encryption. 29 CloudProviderNetwork CloudAccount CloudAccount CloudAccount Instance Secrets Management Key Management & Encryption App DB Disk Managed Service
- 30.
- 31. Speed & Easecan create problems… • Overloaded terms like “Policy” can cause confusion for DevOps and Security teams. • Applying broad controls to narrow problems can create gaps. • Security reviews are too slow… • Mistakes can and do happen!! • Security scanners and testing tools are not yet available for solving these speed & ease challenges. 31 DEVOPS SECURITY CLOUD SECURITY POLICIESSECURITY AS CODE Page 3 of 433 How do I? Did you mean? What is? Sigh…It’s like we aren’t speaking the same language…
- 32. Mixed modes don’twork • Forklifts are not a good idea because the original controls operate different. • Systems designed for waterfall don’t have an easy path to achieve agile. • Fragile applications in the cloud are easy pickings for attackers! 32 MAN – THIS SHELL IS HEAVY!
- 33. Code can solvethe divide • Paper-resident policies do not stand up to constant cloud evolution and lessons learned. • Translation from paper to code can lead to mistakes. • Traditional security policies do not 1:1 translate to Full Stack deployments. 33 DataCenter CloudProvider Network • LOCK YOUR DOORS • BADGE IN • AUTHORIZED PERSONNEL ONLY • BACKGROUND CHECKS • CHOOSE STRONG PASSWORDS • USE MFA • ROTATE API CREDENTIALS • CROSS-ACCOUNT ACCESS EVERYTHING AS CODE Page 3 of 433
- 34. Speed & Easecan increase security! • Fast remediation can remove attack path quickly. • Resolution can be achieved in minutes compared to months in a datacenter environment. • Continuous Delivery has an advantage of being able to publish over an attacker. • Built-in forensic snapshots and blue/green publishing can allow for systems to be recovered while an investigation takes place. 34 APP APP DB DB APP DB ATTACKED FORENSICSRECOVERED
- 35.
- 36. Shift controls &mindset 36 Security Monitoring
- 37. Cloud Security isa Big Data Challenge… • DevOps + Security is the biggest big data challenge ahead. • Use Attack Models and choose the right Data Sources to discover attacks in near real-time. • Develop a scientific approach to help DevOps teams get the security feedback loop they have been looking for. 37 • Web Access Logs • Java Instrumentation • Proxy Logs • DNS Logs
- 38. Cloud Security FeedbackLoop 38 insights security sciencesecurity tools & data Cloud accounts S3 Glacier EC2 CloudTrail ingestion threat intel
- 39.
- 40. Safe experimentation iscritical… • Test possible solutions, arrive at Good Enough. • Crawl-Walk-Run plans can save your org from large-scale incidents. • Keep up with Lessons Learned! 40
- 41. 10DAYS Don’t Hug YourInstances… 41 • Research suggests that you should replace your instances at least every 10 days, and that may not be often enough. • Use Blue/Green or Red/Black deployments to reduce security issues by baking in patching. • Make sure to keep a snapshot for forensic and compliance purposes. • Use config management automation to make changes part of the stack. • Refresh routinely; refresh often!
- 42. Use Cloud NativeSecurity Features... 42 • Cloud native security features are designed to be cloudy. • Audit is a primary need! • Configuration and baseline checks baked into a Cloud Provider’s Platform help with making decisions and uncovering risks early in the Continuous Delivery cycle. • Be deliberate about how to use built-in security controls and who has access.
- 43. Security as Code…gotta do it. 43 By: Peter Benjamin
- 44. Apply what youlearned today… 44 • Next week you should: • Understand how your organization is or plans to use cloud providers • Identify cloud workloads and virtual blast radius within your organization • In the first 3 months following this presentation you should: • Begin to build Security as Code skills and run cloud security experiments to understand the issues • Develop Crawl-Walk-Run plans to help your organization build security into cloud workloads • Within 6 months you should: • Cloud workloads have been instrumented for known security issues and flagged during the Continuous Delivery of software to the cloud • Your group has begun to test using Red Team methods and automation to ensure end-to-end security for your cloud workloads • Remediation happens in hours to days as a result of automation
- 45. Get Involved & Jointhe Community • devsecops.org • @devsecops on Twitter • DevSecOps on LinkedIn • DevSecOps on Github • RuggedSoftware.org • Compliance at Velocity Join Us !!! Spread the word!!! 45