Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

AWS re:Invent 2016: The Psychology of Security Automation (SAC307)

829 visualizaciones

Publicado el

Historically, relationships between developers and security teams have been challenging. Security teams sometimes see developers as careless and ignorant of risk, while developers might see security teams as dogmatic barriers to productivity. Can technologies and approaches such as the cloud, APIs, and automation lead to happier developers and more secure systems? Netflix has had success pursuing this approach, by leaning into the fundamental cloud concept of self-service, the Netflix cultural value of transparency in decision making, and the engineering efficiency principle of facilitating a “paved road.”

This session explores how security teams can use thoughtful tools and automation to improve relationships with development teams while creating a more secure and manageable environment. Topics include Netflix’s approach to IAM entity management, Elastic Load Balancing and certificate management, and general security configuration monitoring.

Publicado en: Tecnología
  • Sé el primero en comentar

AWS re:Invent 2016: The Psychology of Security Automation (SAC307)

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Jason Chan December 2016 SAC307 The Psychology of Security Automation
  2. 2. What to Expect from the Session An inside look at cloud security automation at Netflix How to use the opportunities that AWS and cloud present to make security more ubiquitous Design principles for security automation that improve both security and developer-security relationships
  3. 3. The Psychology of Security Automation
  4. 4. History: Developer - Security Relationships
  5. 5. Opportunities for Developers are also Opportunities for Security Teams
  6. 6. Opportunities + History = Powerful Tools
  7. 7. Design Principles for Security Automation
  8. 8. Design Principles Integrate Security++ Transparency Low Touch and Decoupled Reduce Cognitive Load
  9. 9. SSL
  10. 10. Historic Issues • Expiry-based outages • Security vulnerabilities • Complex configuration SSL/TLS Certificate Management Now with AWS • API-driven config • Centralized management • Machine-readable policies
  11. 11. Lemur
  12. 12. Lemur One-stop shop for SSL certificate management Request, provision, deploy, monitor, escrow Identify SSL configuration issues Plugin architecture to extend as necessary
  13. 13. Lemur Certificate Creation Create and Escrow Keys Create CSR Certificate Authority Issue Certificate Deploy to AWS Account(s)
  14. 14. Lemur Takeaways APIs = Opportunities Focus automation investments on persistent, difficult, common problems Security++
  15. 15. Permissions Management and Access Control
  16. 16. Goal = Least Privilege
  17. 17. But . . .
  18. 18. “It is often easier to ask for forgiveness than to ask for permission” – Grace Hopper
  19. 19. AWS Permissions Management • Innovation is enabled by composition of multiple services, but . . . . • Sophisticated policy language • 2500+ individual API calls • New services and features released weekly
  20. 20. Historic Issues • Least privilege is difficult in practice • Multiple disconnected systems to configure • Low visibility Permissions Management and Access Control Now with AWS • One place for all permissions • API level, API driven • Visibility • Infrastructure as code
  21. 21. Repoman: Right-sizing IAM Permissions
  22. 22. Repoman Benefits Low-risk access reduction Transparent and versioned operations Enables innovation and high-velocity development on AWS Security++
  23. 23. Rollie Pollie – AWS Permissions Management via ChatOps
  24. 24. ChatOps Basics
  25. 25. Rollie Pollie
  26. 26. Rollie Pollie Benefits Engineering-native workflows Transparent decisions Automated, secure, consistent ChatOps allows quicker changes and reduced context switching
  27. 27. Security in the Development Lifecycle
  28. 28. Security in the Agile Lifecycle 17 steps across 7 phases 
  29. 29. Application Risk Assessment
  30. 30. Application Risk Assessment Historic Issues Spreadsheet and human-driven One-time Presupposes managed intake Now with AWS Objective observability Ongoing analysis No humans required!
  31. 31. Penguin Shortbread: Automated Risk Analysis for Microservice Architectures
  32. 32. Penguin Shortbread Operation Passively and continually analyze system dimensions, e.g.: • Instance count • Dependencies • Connectivity to sensitive systems • Internet-accessibility • AWS account location
  33. 33. Risk Assessment Develop risk scoring based on observations Use risk scoring to prioritize efforts
  34. 34. Application Risk Metric Metric summary Metric algorithm Scoring
  35. 35. Application Risk Rollup Metrics Risk metrics by region/environment
  36. 36. Developer View in Context
  37. 37. Penguin Shortbread Benefits Low touch and ongoing Objective and transparent view to application risk Simple prioritization helps reduce cognitive load
  38. 38. Security Requirements
  39. 39. Historic Issues Ambiguous Difficult to verify Security Requirements Now with AWS API-driven implementation API-driven evaluation
  40. 40. Security Requirements via Production Ready
  41. 41. Production Ready SRE-driven developer outreach program Evangelize well-established patterns and practices, e.g.: • Deployment • Monitoring and Alerting • Testing Automated scoring Uncover risk and reward operational excellence
  42. 42. Security-Specific Production Ready Measures App-Specific Security Group App-Specific IAM Role No plaintext secrets in code
  43. 43. Production Ready Scorecard Tracking over time
  44. 44. Production Ready Benefits Security integrated with other measures of readiness Simple to evaluate compliance Paved road lowers cognitive load Easy to extend as capabilities expand
  45. 45. Takeaways • Security teams can and should leverage the high- velocity development ecosystem • Shared history provides both lessons and input to development • Aim to make security more integrated and ubiquitous while also improving other system characteristics
  46. 46. Thank you!
  47. 47. Remember to complete your evaluations!
  48. 48. Related Sessions