APIdays Paris 2019 - RASP for APIs and Microservices by Jean-Baptiste Aviat, Sqreen.io
•
0 j'aime•54 vues
RASP for APIs and Microservices Jean-Baptiste Aviat, Co-Founder & CTO of Sqreen.io
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à APIdays Paris 2019 - RASP for APIs and Microservices by Jean-Baptiste Aviat, Sqreen.io
Similaire à APIdays Paris 2019 - RASP for APIs and Microservices by Jean-Baptiste Aviat, Sqreen.io (20)
Plus de apidays
Plus de apidays (20)
Dernier
Dernier (20)
APIdays Paris 2019 - RASP for APIs and Microservices by Jean-Baptiste Aviat, Sqreen.io
- 1. APIDays Paris 2019 2019/12/10 RASP for APIS and Microservices
- 2. Who am I? Jean-Baptiste Aviat CTO & CO-FOUNDER AT SQREEN EX APPLE RED TEAM Email jb@sqreen.com Twitter @JbAviat
- 3. The world is moving towards microservices
- 4. Monoliths 4 Monolith DB1 DB2 • Huge • Complex • Highly coupled Hard to scale: • Distribute work across teams • Evolve
- 5. Microservices 5 DB DB DB Stream DB Ingestion Monitoring Auth Configuration Worker Analytics • Lightweights • Independents • Simplers • Specialized • 1 team = 1 service Many things change: • Logging • Monitoring • Debugging • …
- 6. Monoliths: how to protect? 6 Monolith DB1 DB2 W A F • 1 entry point. • Perimeter protection is possible.
- 7. Security on a microservice architecture
- 8. In-App WAF User Monitoring Content Security Policy Driver specific protections What is RASP? 8 Sits inside the application Combines several protection layers Usable at scale: • Self configures • Automatically updates • Actionable, developer friendly reports Business logic monitoring Business logic monitoring
- 9. Ingestion Monitoring Auth Configuration Worker Analytics Legacy WAF Limited to the perimeter.
- 10. • The protection is applied to each service • Each service provides insights about the whole architecture Ingestion Monitoring Auth Configuration Worker AnalyticsRASP
- 11. Ingestion Monitoring Auth Configuration Worker AnalyticsRASP • The protection is applied to each service • Each service provides insights about the whole architecture • Decisions can be made about any part of the whole
- 12. Microservices security checklist Single Microservice • Each has the same security challenges than a monolith • No input should be trusted • Check client authentication & authorisation for each action (= zero trust) • Monitor vulnerabilities and attacks 12 Microservice Infrastructure • Cryptographically secure service to service communications • Trace requests origins towards the network’s edge • Leverage your business logic when blocking attacks • Consolidate security logs & monitoring
- 13. Security: zoom on a single microservice
- 14. Risks on one microservice • TL; DR: Same than monoliths. • OWASP Top 10 (top 10 most common vulnerabilities) • Business logic issues • Remember: we broke a monolith apart. • Trust mutual communications. 14
- 15. One service security = as critical as the whole 2 key characteristics of a microservice: • Low coupling • Reusability (by other teams = services) Consequences: • Inputs shouldn’t be trusted • Security controls need to happen at each service level 15 Microservice
- 16. Async workers matter too! 16 DB DB Stream Ingestion Monitoring Auth Configuration Async worker Analytics DB DB They can be exploited in several ways. Exploited flaws can allow to query other services in the network.
- 17. Microservice observability The code • Vulnerable packages • New routes • Vulnerable functions The business logic • Who are my clients / my servers • Am I performing business sensitive operations? • Personal information flowing in my code The users • Account theft attacks • User performing attacks 17 New route detected: /user/:user_id/export users.rb:88 Committed by jon.hopkins on 01.03.2018 SQL injection blocked authorization.mycompany.com Framework: Gin 1.5.0 Databases: PostgreSQL, MongoDB New Go 1.13 service detected: “Authorization”
- 20. Attacks: trace them back to the attacker 20 DB DB DB Stream DB Ingestion Monitoring Auth Configuration Worker Analytics• Attack blocked on a nested service • Need to be traced back to the external attacker
- 21. 21 •Apply cryptography •Mutual authentication Bound to a channel: ✅ Analytics → Auth ❌ Analytics → Configuration Zero trust: Authentication & authorisation per service Service to service communications DB DB DB Stream DB Ingestion Monitoring Auth Configuration Worker Analytics
- 22. How to respond to attacks in a microservice architecture?
- 23. Block the actor at the edge 23 DB DB DB Stream DB Ingestion Monitoring Auth Configuration Worker Analytics Blocked actors are fully isolated But errors are dramatics ❌ ❌ ❌
- 24. Block only sensitive services 24 Bad actor detected: hacker@somedomain.com Prevent access to services: Analytics, Auth • Some sensitive services are denied • Best effort to keep providing functionality to the blocked actor DB DB DB Stream DB Monitoring Auth Configuration Worker Analytics ❌❌ ❌ ❌
- 25. Decrease rights of a given actor 25 DB DB DB Stream DB Monitoring Auth Configuration Worker Analytics Bad actor detected: hacker@somedomain.com —> Deny all further authorisations • Fine grained approach • Depends on business logic • Prevent only some business sensitive actions • Best to keep providing some level of service
- 26. Questions?
- 27. Lexicon SSRF: vulnerability that can allow to query internal micro services RCE: outcome of some vulnerabilities exploitation. Allows to query internal micro services. East/West: service to service communications North/West: external world to service communications OWASP top 10: top 10 most common vulnerabilities mTLS: two ways cryptographic authentication Micro Perimeter: perimeter of 1 micro service ALTS: Application Layer Transport Security 27