Download as PDF, PPTX
Uploaded byTrupti Shiralkar, CISSP
Zerotrusting serverless applications protecting microservices using secure design patterns 3.0
Trupti Shiralkar presented on securing serverless applications and microservices. She began with an overview of serverless architectures and microservices, noting the evolution from monoliths and increased security challenges from complexity and dynamic interactions. She then analyzed common microservices security design patterns like API gateways, JSON web tokens, circuit breakers, service meshes, and log aggregators. Finally, she discussed best practices for securing serverless applications, including zero trust, input/output validation, secret handling, security scanning in CI/CD, and conclusion security testing. The presentation provided context on serverless architectures and microservices before analyzing related security patterns and recommendations.
More Related Content
Similar to Zerotrusting serverless applications protecting microservices using secure design patterns 3.0
Zerotrusting serverless applications protecting microservices using secure design patterns 3.0
- 1. Zerotrusting Serverless Applications: Protecting Microservicesusing Secure Design Patterns Trupti Shiralkar
- 2. About Me • PrincipalApplication Security Engineer, Illumio • Mobile game developer turned security professional - MS In Security Engineering, Johns Hopkins University - Previously worked at Amazon, Q2Ebanking, HP & ATSEC • When I am not doing security - Travel - Paint • Yoga Alliance Certified Instructor - Breathing exercises - Meditation Twitter: @tshiralkar LinkedIn: https://www.linkedin.com/in/trupti-shiralkar-0a085a8/ Email: s.trupts@gmail.com
- 3. Agenda ● Understanding serverlessapplications and microservices ● Analyzing microservices security design patterns ● Securing serverless applications and microservices
- 4. Understanding Serverless and Microservices ● Evolution ●Security pain points ● Overall changing role of security
- 5. Evolution of SoftwareArchitecture
- 6. What exactly isserverless ? Serverless Ecosystem Serverless Functions (AWS Lambda) Serverless Applications (AWS dynamo DB) Serverless Containers AWS (Fargate) • No management of servers • Operational tasks done by cloud provider • Event driven • Stateless • Short lived • On demand scalable • Pay as you use
- 7. Monolith vs Microservicesvs Serverless Attributes Monolith Microservices Serverless Modularity Tightly coupled Loosely coupled Loosely coupled Interservice Communication Smart pipes, heavy weight protocol, SOAP Dumb pipes, lightweight protocols such as REST and gRPC REST APIs Data Global data model, shared database Data model and database per service Data model per function, ephemeral Typical Service Giant Monolith Application Small independent Services Short lived, event driven, stateless, pay as you used functions Deployment slow faster Super fast
- 8. Microservices are notsilver bullet! Credit: KRAZAM
- 9. Security pain points ●Increased complexity ● Implicit trust is dangerous ● Static vs Dynamic Order of API calls ● Serverless attack surface is unknown ● Inadequate security tooling can’t detect vulnerabilities in microservices ● Traditional application security lacks the speed of development & deployment
- 10. OWASP vulnerabilities arestill applicable ● A1: Injection ● A2: broken Authentication ● A3: Sensitive Data Exposure ● A4: XML External Entities ● A5: Broken Authentication ● A6: Security Misconfiguration ● A7: Cross-Site Scripting (XSS) ● A8: Insecure Deserialization ● A9: Using components with known Vulnerabilities ● A10: Insufficient Logging & Monitoring
- 11. AWS Lambda Available since2014 Code Injection Access Bypass - CVE- 2015-3373 Command Injection- CVE- 2019-10777 ● Debugging through logging ● Limited testing ● Temp data leakage ● Misconfigured IAM policies using wildcards ● Command Injection in CLI tool of AWS- Lambda
- 12. Changing role ofsecurity
- 13. Microservice Design Patterns ● Whatare microservice design patterns? ● Why do we need it? ● Can we leverage them to achieve security goals?
- 14. Design Patterns forMicroservices Decomposition patterns Integration patterns Database patterns Observability patterns Cross-Cutting Concern patterns Decompose by Business Capability Decompose by Subdomain Decompose by Transactions Strangler Pattern Bulkhead Pattern Sidecar Pattern API Gateway Pattern Aggregator Pattern Proxy Pattern Gateway Routing Pattern Chained Microservice Pattern Branch Pattern Client-Side UI Composition Pattern Database per Service Shared Database per Service CQRS Event Sourcing Saga Pattern Log Aggregation Performance Metrics Distributed Tracing Health Check External Configuration Service Discovery Pattern Circuit Breaker Pattern Blue-Green Deployment Pattern Image credit: https://medium.com/@madhukaudantha/microservice- architecture-and-design-patterns-for-microservices-e0e5013fd58a
- 15. API Gateway API Gateway •Login (IAM) • DOS protection • API Authorization • Routing of Request • Throttling, API rate limit & load balancing • HTTPS endpoints • Security and resiliency monitoring • Logging and auditing • Caching for better latency Still vulnerable to attacks • Layer 7 DDOS with counterfeit requests • DDOS with cascading requests • Layer 3 DDOS with syn flood • Implementation specific Login/Identity attacks • Static API key abuse • Common web application attacks like XSS, SQLi
- 16. JSON Web Token •Authentication of APIs • Authorization with each request • Service to service authentication • Service to service communication • Vulnerable to implementation attacks - JWT cipher misconfiguration (none) - JWT reply attack (jti) - JWT information leakage
- 17. Circuit Breaker DesignPattern Circuit Breaker Pattern • Handles failure gracefully • Prevents catastrophic cascading failure across multiple systems • Good for monitoring, logging and overall recovery • Fault tolerant • Resilient • Example: Netflix's Hystrix library Attacks • Breaker to broker- DDOS • API Gateway can be single point of failure
- 18. Service Mesh DesignPattern Service Mesh • Inter-service communication infrastructure • Authentication and authorization of services • mTLS for inter-service communication • Enforcing security policies Vulnerable to attacks • Security misconfigurations • Increased complexity
- 19. Log Aggregator DesignPattern Log Aggregator • Collection of all logs • Real time monitoring of anomaly patterns (deviation from regular pattern) • Automated notification Limitations + Attacks • Correlation of logs across microservice • Logging sensitive information • Unauthorized access to logs
- 20. Securing Serverless Applications and Microservices ● Security bestpractices ● Security scanning and tooling
- 21. Security best practices ●Zero trust everything (code, applications, inter-process communications, configurations, networks ) ● Select encryption at rest wisely ● Secure coding convention must be followed ● Generate logs, perform auditing and monitoring, use SIEM ● Stay on top of 3rd party known CVEs associated with open source libraries ● Involve your security team early
- 22. Secure Communication TLS Attacks: •ROBOT (1998-2017) • EC DRBG Backdoor (2007-2013) • Lucky 13 (2013) • BEAST (2013) • POODLE (2014) • Heartbleed (2014) • Logjam (2015) • FREAK (2015) • DROWN (2016) Security Best Practices • Do not use insecure SSL protocols (SSLv3, TLS 1.0, TLS 1.1) • Use cipher with 128+ bit of cryptographic strength (AES-256, RSA 2048, SHA-256 +) • Crypto agility (plan for TLS 1.3) • Mutual TLS
- 23. Input and OutputValidation
- 24. Secure handling andstorage of Secrets
- 25. Security Scanning withinCI/CD Containers and Orchestration security - CIS benchmark - Clair - Dagda - Anchore - KubeSec - Kubehunter (RASP) - DAST - IAST
- 26. Security Testing ofMicroservices ● Security unit test cases ● Perform threat model to abuse cases ● Build scanners for detecting common application security vulnerabilities
- 27. Conclusion ● Begin withZerotrust by default ● Earn trust as you validate the authenticity of serverless applications ● Vetted microservice design patterns foster security ● Classic AppSec attacks are still applicable ● Be open minded about modern security tooling ● Automating AppSec tools promote shift left security transformation ● Threat Modeling is priceless ● Secure the complete stack and not just microservices
- 28. References Chris Richardson SamNewman Prabhat Siriwardena Newan Dias Jim Manico & many contributors Heather Adkins Bestsy Beyer Paul Blankinship Piotr Lewandowski Oprea & Adam Stubblefield
- 29.