Secure by design: introduction to threat modeling

An introduction to threat modeling and some ideas on how to integrate it in yours teams.

Transcript

1. Secure by design Threat modeling Jérémy Courtial - Software Security Architect
2. How to ship secure applications?
3. Vulnerability: a very nasty kind of bug Oxford dictionary
4. Good news! We know how to handle bugs!
5. Design Test Implement Deploy
6. Design Test Implement Deploy Threat modeling
7. Design Test Implement Deploy Secure coding Trusted libraries Code reviews
8. Design Test Implement Deploy Fuzzing Pen tests
9. Design Test Implement Deploy Secure environment Monitoring Incident responses
10. Threat modeling?
11. What you all want… $ ./threat_model app.jar Analyzing… Done. You’re fine! Good job!
12. Sorry
13. Threat modeling: A process to identify and prioritize structural threats in applications
14. How to? - decompose your app - find threats - decide what to do
15. 1. What are you building?
16. List entities, processes, data stores and data flows
17. Architecture and communication diagrams are good starting points
18. Otherwise, use a whiteboard!
19. Client App Web Server Database Offsite Storage
20. Client App Web Server Business Schema Offsite Storage Metrics Schema
21. Client App Web Server Database Offsite Storage Request file Read file metadata Read file Download file
22. Client client hello TLS versions, cipher suites, … server hello Selected version/cipher, certificate, … client key exchange encrypted pre-master key Verify certificate, parameters Decrypt using private key Server Encrypt using public key
23. Now the most important part: add trust boundaries
24. Trust boundaries make explicit different levels of privilege
25. Client App Web Server Database Offsite Storage Production datacenter Cloud provider
26. Trust boundaries help you focus your efforts where they matter
27. 2. Find threats
28. Threats tend to appear around trust boundaries.
29. But how to find them?
30. R S E D I T Useful mnemonic/framework:
31. R S E D I T
32. R S E D I T poofing
33. R S E D I T poofing ampering
34. R S E D I T poofing ampering epudiation
35. R S E D I T poofing epudiation nformation disclosure ampering
36. R S E D I T poofing epudiation nformation disclosure enial of service ampering
37. R S E D I T poofing epudiation nformation disclosure enial of service levation of privilege ampering
38. Publisher Broker Subscriber
39. Publisher Broker Subscriber What? Tampering Information disclosure How? Man-in-the-middle
40. Publisher Broker Subscriber What? Spoofing How? Man-in-the-middle Malicious Broker
41. Publisher Broker Subscriber What? Spoofing How? Unauthorized publisher
42. Publisher Broker Subscriber What? Spoofing How? Unauthorized subscriber
43. Publisher Broker Subscriber What? Information disclosure How? Unauthorized subscriber Unsecure persistence mechanism
44. Publisher Broker Subscriber What? Tampering How? Unsecure persistence mechanism
45. 3. Decide what to do
47. Nope (except if you’re the NSA)
48. For each threat: First, evaluate the risk (impact, probability, exploitation, etc.) Then, choose a strategy
49. Redesign to eliminate Remove vulnerable features Add features reducing the risk
50. Mitigate Apply standard mitigations Design new ones (riskier)
51. Accept the risk Make the risk explicit You could also transfer it
52. Never ignore threats (one word: GDRP)
53. Publisher Broker Subscriber What Tampering Information disclosure How Man-in-the-middle Strategy Mitigate: use TLS
54. Publisher Broker Subscriber What Spoofing How Man-in-the-middle Malicious Broker Strategy Mitigate: use TLS Mitigate: use authentication
55. Publisher Broker Subscriber What Tampering How Unsecured persistence mechanism Strategy Accept risk? Redesign: disable persistence? Mitigate: setup system-level protections? Mitigate: encrypt end-to-end?
56. You don’t have one threat model Final note
57. How to integrate threat modeling in your R&D?
58. Schedule a 4 hours meeting Invite half the devs, half the ops and some people with long titles Have them produce a 20-pages long threat model
59. Do what fits your culture
60. Dedicated meetings/projects Back-to-the-envelope Opportunistic meetings How?
61. Whiteboard picture Meetings notes Full documentation Delivery?
62. Don’t care. Just do it.
63. Architecture reviews Threat modeling @ Oodrive
64. Feedbacks-oriented meeting before any major changes enter development Eg. new service, major refactoring
65. Ensuring best practices Identifying subjects that need closer follow-ups Providing feedbacks and challenging architectural choices
66. Not a threat modeling meeting per-se… … more like « Hey! While we’re all here … » Parasite-security
67. Security checklists Threat modeling @ Oodrive
68. Use HSTS Must be HTTPS-only Store secrets inside Vault Have anti-CSRF mechanism … See Spring-Security ?
69. Ready-to-use (implicit) threat models Focus on mitigations Validated during security reviews
70. Slack’s goSDL Threat modeling elsewhere https://github.com/slackhq/goSDL https://slack.engineering/moving-fast-and-securing- things-540e6c5ae58a
74. Should you threat model?
75. Yes! (obviously)
76. At least once
77. Know your(s) threat model(s)!
78. Questions? Thank you To win! Icons created by Tomas Knopp, Edwin Prayogi M and Dima Lagunov from the thenounproject.com