Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

(SEC320) Leveraging the Power of AWS to Automate Security & Compliance

5,527 views

Published on

"You’ve made the move to AWS and are now reaping the benefits of decreased costs and increased business agility. How can you reap those same benefits for your cloud security and compliance operations? As building cloud-native applications requires different skill sets, architectures, integrations, and processes, implementing effective, scalable, and robust security for the cloud requires rethinking everything from your security tools to your team culture.  

Attend this session to learn how to start down the path toward security and compliance automation and hear how DevSecOps leaders such as Intuit and Capital One are using AWS, DevOps, and automation to transform their security operations.

Session sponsored by evident.io"

Published in: Technology

(SEC320) Leveraging the Power of AWS to Automate Security & Compliance

  1. 1. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Tim Prendergast @auxome / @evidentdotio Security Beyond the Host Leveraging the power of AWS to Automate Security and Compliance Shannon Lietz, Intuit Brett Lambo, Capital One SEC 320
  2. 2. Of the changes catalyzed by cloud, security is the most exciting.
  3. 3. Legacy Datacenters • Big Perimeter • End-to-End Ownership • Build it all yourself • Server-centric approach • Self-managed Services • Static Architecture • De-centralized Administration The security paradigm shifted AWS • Micro-Perimeters • Own just enough • Focus on your core value • Service-Centric • Platform Services • Continuously Evolving • Central Control Plane (API)
  4. 4. Your Role in Securing AWS is Well-Defined Customer Data Applications Identity Access Mgmt OS Network Firewall Client-side Encryption Server-side Encryption Network Traffic Protection Compute Storage Networking AWS Global Infrastructure (Regions, Azs, Edge Locations) AWS: Security of the Cloud Customer: Security in the Cloud
  5. 5. … but the security technology has lagged Customer Data Applications Identity Access Mgmt OS Network Firewall Client-side Encryption Server-side Encryption Network Traffic Protection Network Appliances Host-based Agents IP-based scanners Log Analytics DLP & Encryption Manual Audits These technologies don’t embrace cloud values…
  6. 6. Host-centric Security Strategies fail in AWS Protecting the host while ignoring the services is a bad decision. Your most critical data often lives in S3, Glacier, RDS, Redshift, and other key services.
  7. 7. Point solution strategies create focus-lock Customer Data Applications Identity Access Mgmt OS Network Firewall Client-side Encryption Server-side Encryption Network Traffic Protection Compute Storage Networking AWS Global Infrastructure (Regions, Azs, Edge Locations)
  8. 8. Appliances don’t scale well How many of these do I need at various levels of scale?
  9. 9. … and don’t get me started on manual audits!
  10. 10. Freshen the stack This is all you (no change) Hasn’t changed much Cloud-aware Agents API-driven security API-driven security API-driven security API-driven security + AWS This is all AWS…
  11. 11. Why the API is so critical “Imagine the ability to create or destroy an entire datacenter with just the proper credentials, or a short script.” - Adrian Sanabria, 451 Group
  12. 12. Advantages to the API • Authoritative - The ONLY interface to 95% of AWS • Fast - can be read and manipulated in sub-second time • Precise – defines the state of infrastructure • Evolving – continuously improving (Thanks, AWS!) • Uniform - provides consistency across disparate components • Automatable - Enables some really, really cool capabilities
  13. 13. Actioning security in the cloud means… See It Consume It Live It Develop Test Assess Push Assess Observe Continuous Assesment Innovate
  14. 14. Capital One Venture to the Cloud Brett Lambo, Sr. Director of Information Security & Risk Management Michael Shriver, Lead Cloud Security Architect
  15. 15. Zero to Cloud in Five Months • Capital One is on an aggressive digital journey. • Innovation, customer experience, and time to value are king. • In November, 2014 we declared that we would have production applications in AWS by April 1, 2015. • This was not a prank.
  16. 16. What were we Thinking? • We were thinking, “But wait. We’re a bank. With regulators. With money. With credit cards.” • We’re lucky though: From the top, Capital One views security as a fundamental partner of innovation. • Security had to be faster than the business. We needed to be there waiting for them. • How would we secure our data across the full range of AWS services…not just EC2?
  17. 17. Some Fundamental Considerations • Lean forward on encryption. • Require encryption of all EC2, RDS, S3 resources. • But: Key management is inconsistent or unsupported across services and DBs. • We are working with AWS to develop end-to-end crypto and key management platform. • Wrote our own REST encryption/tokenization solution. • Cross between CloudHSM and in-house • Network and connectivity decisions • LOB-specific VPCs. • Creative routing and connectivity
  18. 18. All your Assumptions are Belong to Wrong • We quickly learned that you must ask the right questions to get to the right answers. • Like most, we began trying to adapt our existing security kit to cloud. Oops. • Conclusion: What we do will not necessarily change. How we do it will. How do we extend our DLP to cloud? Belgium.
  19. 19. Data + Software > Appliances and Reports • We have telemetry and data like never before • But we learned that we have to wrangle it • The promise of automation • Security and compliance • Continuous assessment • Security deployment • Chef, Cloud Formations Templates • Enforcement and Remediation
  20. 20. Working through our Build • Need: Provide dedicated Line of Business (LOB) environments with centralized control of security • Limit blast radius (security and operational) • Account for differences between LOBs • Variable demand, apps, types of data • Connectivity and access • Approach: Shared security model with novel approach to routing and deployment across VPCs • Horizontal shared services VPC • Routing skulduggery • How do you get there from here?
  21. 21. What’s next? • Continue to automate • Support DevOps • Leverage Open Source • e.g. Hygieia: Tie together disparate systems and services to centralize our view and management • Master operations
  22. 22. Security + Maturity = DevSecOps Shannon Lietz, DevSecOps Leader at Intuit
  23. 23. Continuous Security Develop • Integrate Secure Components • Develop attacks as part of the workload • Style Matters Test • Implement automated security tests • Fast failure detection improves workloads Deploy • Red Team your stack • Respond and contain quickly!!
  24. 24. Get Rugged -- DevSecOps OPS SEC DEV AppSec • Security as Code • Self-Service Testing • Red Team/Blue Team • Inline Enforcement • Analytics & Insights • Detect & Contain • Incident Response • Investigations • Forensics
  25. 25. Security drives Faster Pipelines • Use Code Commit, Code Deploy & Code Pipeline • Push many small changes per day to support fast defect discovery & remediation • Restack often (Less than 10 days) • High performers have better security
  26. 26. Faster Feedback = Continuous Compliance Boring: PCI DSS1.1.1 – Approve/Test/Detect firewall changes Fun: Scan API + Ingest Config/Cloudtrail, trigger fw audits and revert unapproved changes Boring: PCI DSS2.2 - Develop & Assure configuration standards for all system components. Fun: Track known good CF stacks & AMIs, alert or neutralize non-compliant/non-approved deploys.
  27. 27. Faster Feedback = Continuous Compliance Boring: HIPAA 164.312(a)(2)(iv): Implement a method to encrypt and decrypt electronic protected health information. Fun: Enforce encryption of all assets with HIPAA or data classification tags. Continuous enforcement! (KMS!) Boring: NIST800-53 AC2(12) – Monitors and report atypical usage of information system accounts. Fun: Cloudtrail/Config user attribution of use/abuse. More Fun: Maps to PCI DSS7.1.3, COBIT DS5.4, ISO17799, and more!
  28. 28. Full Stack Attack • API KEY EXPOSURE -> 8 HRS • DEFAULT CONFIGS -> 24 HRS • SECURITY GROUPS -> 24 HRS • ESCALATION OF PRIVS -> 5 DAYS • KNOWN VULN -> 8 HRS
  29. 29. You must apply whole-cloud security Control Plane Critical Infrastructure Core Infrastructure
  30. 30. At the front door… Core Infrastructure Apps (ECS, EC2, Beanstalk) Transport (VPC, ELB, NACLs) Foundation (Route53, DC, Gateways) • Eval/Modify SGs dynamically • Design for blast radius in Transport layers • Detect and guard Foundation services… poisoned R53 is game over.
  31. 31. The back door… Critical Infrastructure Data (S3, Glacier, RDS) Management (OpsWorks, CF, Code*) Identity (IAM, Directory) • Enforce encryption consistently (KMS) • Idempotently deploy/replace entire stacks • Defend identities, tightly scope rights
  32. 32. And the magical portal! Control Plane (AWS API) Audit (CloudTrail, Config, 3rd Party) Respond (Humans, Lambda, Scripts) • Centrally audit all regions/accounts • Create security triggers on audit data • Action a response – page a Human, trigger Lambda, even auto-remediation scripts.
  33. 33. Next Steps… 1. Watch Shannon’s Session SEC402 when it hits Youtube 2. Visit the Evident.io blog and resource page: https://evident.io 3. Talk with the Evident team at Booth #814 to dive deeper 4. Find one of your peers here and talk security!
  34. 34. Thank you! Be sure to visit Evident.io at Booth #814
  35. 35. Remember to complete your evaluations!

×