Hardening Microservices Security: Building a Layered Defense Strategy
•
2 likes•13,605 views
Microservices architecture is forcing developers to not only rethink how they design and develop applications, but also common security assumptions and practices. With the decomposition of traditional applications, each microservice instance represents a unique network endpoint, creating a distributed attack surface that is no longer limited to a few isolated servers or IP addresses. In this presention, we will review: -How microservices differ from SOA or monolithic architectures -Best practices for adopting and deploying secure microservices for production use -Avoiding continuous delivery of new vulnerabilities -Limiting attack vectors on a growing number of API endpoints -Protecting Internet-facing services from resource exhaustion
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to Hardening Microservices Security: Building a Layered Defense Strategy
Similar to Hardening Microservices Security: Building a Layered Defense Strategy (20)
More from Cloudflare
More from Cloudflare (20)
Recently uploaded
Recently uploaded (20)
Hardening Microservices Security: Building a Layered Defense Strategy
- 1. Securing Microservices Threat Modelling and Session Security Presented by David Hoelzer (SANS) and Matt Silverlock (CloudFlare)
- 2. What is a "microservice"? (and what security challenges do they bring?)
- 3. What is a microservice? ● Modular approach to building services. ● Reinvention of the Service Orientated Architecture (SOA) model. ● Micro-services often declare API contracts, but development & deployment are self-contained.
- 4. What is a microservice? Benefits ● Less coupling: easier to reason about changes. ● Apply the most appropriate technology to the problem at hand ● Better suits larger organizations with multiple teams. ● Easier to test when self-contained: less infrastructure to spin up when iterating.
- 5. What is a microservice? Challenges ● Multiple moving parts: more surface area to secure as services communicate to each other. ● Can add complexity into smaller organizations: more tech stacks to maintain, update and patch. ● The need to define formal API contracts so that services can reliably communicate to each other with different development cycles.
- 6. Threat Modelling Understand what you're defending against.
- 7. Threat Modelling ● Stop thinking about what it’s supposed to do ○ Stand back and try to think about how someone could abuse it ○ Start where you have security mitigations ○ Next, think about where you don’t and the assumptions made
- 10. Threat Modelling
- 11. What’s the Point? ● Organizations have many mitigations ○ Firewalls, AV, IDS, etc. ● The threat is not clearly identified by any single activity ○ It’s the behavior rather than a signature
- 12. What’s the Point for Microservices? ● Monolithic Web Applications ○ Session issues are a very well known problem ● Microservices ○ We still have sessions, but they are often far more stateless! ○ How do we define an authenticated “session”? ○ Are there behaviors that we can defend against?
- 15. Threat Modelling ● Everyone watches for repeated authentication failures ○ Do you currently include anything in the session verification process?
- 16. Threat Modelling ● API keys are a possible approach ○ Issue public/private keypair ○ All requests must be signed with public key ■ more computation, but not awful ● How critical is it that the API keys are protected by end users or apps?
- 17. Threat Modelling ● Session issues are not new ○ Microservices changes the game since these are inherently non-monolithic applications ○ It is critical that the, “We do one thing well” philosophy include a thoughtful analysis of potential threats and exposures ● Requires threat-focused defensive coding
- 18. Layered Defenses There are no silver bullets.
- 19. Layered Defenses ● Offload work to the network edge: validate traffic (firewall, reputation, rate limiting) before it reaches your services.
- 20. Layered Defenses ● Protect your resources: prevent outside attackers from consuming resources (spawning more containers may not be the solution)
- 21. Layered Defenses ● Protect your data: multiple discrete services now accessing shared datastores. Each service should only access what it needs, and no more.
- 22. Layered Defenses ● Secure containers: authenticate endpoints, support revocation, and keep images updated.
- 23. Layered Defenses ● Know what you're running: always pulling down the latest image from an image repository or from GitHub may not be a great idea.
- 24. Layered Defenses ● Manage secrets: do your microservices have access to the secrets they need, and only the secrets they need?